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

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_at_dbalert.eu> 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.

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