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

From: David Taft <>
Date: Fri, 1 Feb 2008 10:57:47 -0500
Message-ID: <>


The initial indication on some of the throughput graphs do indicate that something like this was happening, which is why the DBAs on this task thought it was network related. I can't blame them for thinking that since every other time these type of issues have been network related. However, I just received the preliminary results from the new round of testing. Initial indications are that it is a 9i to 10g issue. Hmmm, maybe a consistent test plan with minimal variables is paying off? The plan now is see what happens with a 10g listener on the 9i source database, so that there is a 10g listener servicing both ends. I will keep the list posted and thanks for everyones' input thus far.


On Feb 1, 2008 9:53 AM, Carel-Jan Engel <> wrote:

> 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?

Received on Fri Feb 01 2008 - 09:57:47 CST

Original text of this message