Re: The problem is that SQL*Net is too chatty, because FTP runs fine.

David,

Recently I ran into a performance issue regarding WAN at a CT. It appeared that the bandwidth for alomost any port was cut down by the router when traffic/second crossed a treshold for a (short) period of time. A burst of network IO would start fast, but then collapse. This was set up deliberately by NW admins to protect other users from large transfers. Our transport burst was also a SQL*Net thing, involving Data Guard closing gaps. We got around it by setting up dedicated ssh tunnels, over dedicated ports. The primary connects to a localhost:<portno> now, this port is tunneled to the listener port of the standby. The port used for the tunnel got its own QOS settings, so that we have constant bandwidth available now.

Could something like this bandwidth-cutting be happening at your site?

Best regards,

Carel-Jan Engel

===
If you think education is expensive, try ignorance. (Derek Bok) ===

On Fri, 2008-02-01 at 09:16 -0500, David Taft wrote:

> Nigel,
>
> I agree about running tnsping. I plan on running my own tests today
> and the first step is to run tnsping starting with a 10 count,
> incrementing by 10-fold with each successive run, and parsing the
> output to get the min, max and average response times. I do know we
> have been faked out in the past due to a SQL*Net proxy server in the
> firewall returning our tnsping rather than the actual target listener,
> but I don't believe this will be the case on these two WANs.
>
> Up till now I have only been brought in so that ideas could be bounced
> off of me. I have not been the one actually doing the testing. I
> have tried to emphasize the importance of consistency. By consistency
> I mean running the tests across each WAN with a minimal number of
> variables. For instance, originally it was my understanding that the
> materialized view refresh was 10g to 10g, but yesterday I found out
> that the source is 9i and the target is 10g, but some of the tests
> were done 9i to 9i and others 9i to 10g. My opinion was that those
> tests are invalid. The two DBAs who have been wrestling with this
> issue are currently rerunning those tests.
>
> David
>
>
>
> On Feb 1, 2008 4:21 AM, Nigel Thomas <nigel_cl_thomas_at_yahoo.com>
> wrote:
>
> David
>
>
>
> Just a quick thought: you say they've blocked ping, but
> (pardon my network naivety if necessary) is there a reason you
> can't tnsping? If you can run a few tnsping samples over both
> routes you would soon know if there are inherent differences
> in network latency.
>
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

--
http://www.freelists.org/webpage/oracle-l