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

  • From: "David Taft" <oradbt054@xxxxxxxxx>
  • To: "Carel-Jan Engel" <careljan@xxxxxxxxxx>
  • Date: Fri, 1 Feb 2008 10:57:47 -0500

Carel-Jan

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.

David

On Feb 1, 2008 9:53 AM, Carel-Jan Engel <careljan@xxxxxxxxxx> 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?
>
>
>

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 02-2008