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

From: Carel-Jan Engel <careljan@xxxxxxxxxx>
To: oradbt054@xxxxxxxxx
Date: Sat, 02 Feb 2008 00:32:57 +0100

Whether compression brings you anything, depends. E.g. when dealing with
Data Guard, synchronous redo transport has a nature of many small
packets being sent. CPU usage (by ssh compression) increases, whilst
there is not that much benefit. When Data Guard uses ARCH for redo
transport (i.e. complete archived redo log files get sent) the
compression is better, whilst CPU usage is less significant. All
mileages vary, so conduct your own tests for this.

I use some ksh scripting to monitor the tunnel and bring it back to live
when it dies, and just in case it would fail completely, I have the tns
alias defined with connect time failover. The second entry will use the
direct connection to the standby, circumventing the tunnel, losing the
QOS defined for the tunnel. But after all, it's the backup connection. I
even have a CT set up with 3 entries: tunnel 1 throught the dedicated
net, tunnel 2 through a public internet connection, tunnel 3 direct
throught the dedicated net. If the first connection fails, it will just
try the next, and so on. Quite robust.

HTH
Best regards,

Carel-Jan Engel

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

On Fri, 2008-02-01 at 11:30 -0500, David Taft wrote:

> Carel-Jan,
> 
> I just reread this post.  Even if this issue is not a caused by the
> network, the ssh suggestion is a great idea for potential future
> issues that are of the network nature you described.  We use ssh
> tunnels around here a lot from our desktops to remote databases, but
> have yet to try server to server tunnels.  Did you use ssh compression
> for that tunnel?
> 
> David
> 
> 
> On Feb 1, 2008 9:53 AM, Carel-Jan Engel <careljan@xxxxxxxxxx> wrote:
> 
>         
>         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. 
>         
>         
> 
> 
> 
> -- 
> This message has been scanned for viruses and 
> dangerous content by MailScanner, and is 
> believed to be clean.

References:
- Re: The problem is that SQL*Net is too chatty, because FTP runs fine.
  - From: Nigel Thomas
- Re: The problem is that SQL*Net is too chatty, because FTP runs fine.
  - From: David Taft
- Re: The problem is that SQL*Net is too chatty, because FTP runs fine.
  - From: Carel-Jan Engel
- Re: The problem is that SQL*Net is too chatty, because FTP runs fine.
  - From: David Taft

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

Other related posts: