Re: The problem is that SQL*Net is too chatty, because FTP runs fine.
Date: Fri, 1 Feb 2008 10:57:47 -0500
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 <careljan_at_dbalert.eu> 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?