Standby db question

I would like to run something by you all -

Environment: Win2k3 Server, Oracle 9.2.0.6, physical standby arrangment. The standby server is on the far end of a DS3. Archivelogs are sized at 125MB. At times the standby falls fifteentwenty  logs behind (over an hour).

Problem: We cannot beat an effective transfer rate of 200Kbps. This appears to be due to the ARCH process writing 1MB chunks at a time (not the most efficient way to use the DS3 connection), and of course RFS won't release the log to be recovered until the whole thing gets there.

Initially I set up an ssh tunnel, hoping the gzip compression coupled with OS-level control of the transfer would speed throughput. That is how we realized the ARCH process multiplexing was causing the problem.

Testing with a local standby server was fine - it flew. No bottleneck whatsoever. The local network is 1GB ethenet. So, one cannot blame Windows TCP issues alone (that #$&*! 8MB window limit) for this.

Copying archivelogs down the DS3 manually via xcopy allows us to use the full capacity of the line (subject to Windows TCP limitations). So here is what we are thinking of setting up in place of a standard Data Guard installtion:

1. Local archivelog destination only;
2. Use xcopy (with the /d switch) to move archivelogs down to the standby server;
3. Have the standby db recover them there.

FAL is superannuated, obviously. As xcopy would run on a scheduled basis, we would use it to recover any corrupted logs sent (we are testing this now, it looks promising). Business policy mandates a manual switchover, so lack of failover is not an issue here. As the database is already set up as a physical standby, it will be easy enough to make it a primary should the need arise.

Does anyone see any gotchas in this scheme? Feedback would be appreciated.

TIA - jh Received on Mon Jan 09 2006 - 13:44:20 CST