Database-- Redo Transport Compression Custom Method

As we know, Redologs/Archivelogs produced from Production environments are transported and applied to the Standby environments..  This is Oracle 's standard Disaster Solution, known as Standby Database, and managed through the Data Guard..

In Oracle Data Guard Disaster Solution, all the redo produced in Production database are transferred to the Standby database server, and then Standby database server is updated by the transferred redo entries..
Transfering phase of this disaster solution sometimes become a bottleneck, due to slow networks, or excessive redo generation..

At this point, the compression is included to solve this network bottlenecks. Compressed redo become smaller in size, and require less network throughput.

With 11g Oracle can make compressed redo transportation.. But in order to use Oracle 's standard compression technique, Advanced Compression option should be licensed.. ( you need to buy Advanced Compression license)..
Oracle Support Doc : 729551.1
Redo transport compression is a feature of the Oracle Advanced Compression option. You must purchase a license for this option before using the redo transport compression feature.  Compression of redo transport for versions prior to Oracle Database 11g Release 1 can be accomplished using third party WAN accelerators, such as those available from Cisco, Riverbed, F5, and other vendors.

On the other hand, compressed redo transportation can be accomplished by a custom method, too..
Basically, this method is based on a ssh tunnel, and ssh compression..

Here are the steps :

1) Create ssh equivalence between oracle software owner os accounts in production and standby servers..

IN PROD and STANDBY with oracle user;

mkdir ~/.ssh
chmod 755 ~/.ssh
/usr/bin/ssh-keygen -t rsa
/usr/bin/ssh-keygen -t dsa

IN PROD with oracle user;

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
ssh oracle@standbyserver cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keysssh oracle@ds2 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
chmod 644 ~/.ssh/authorized_keys

IN STANDBY with oracle user;

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
ssh oracle@ds1 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh oracle@ds1 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
chmod 644 ~/.ssh/authorized_keys

2)Create ssh tunnel from production to standby server. -f option will make it run in the background and -C will make it to run in compression mode.

/usr/bin/ssh -f -C -N -L LOCALPORT:REMOTESERVER:REMOTEPORT

3)Stop redo transportation in Production.

sqlplus "/as sysdba"
SQL> alter system set log_archive_dest_state_2=defer;
alter system switch logfile;

4)Change Standby tns entry in Production to use the ssh tunnel.

STDBY.EXAMPLE.COM.TR =
(DESCRIPTION=
(SDU=32768)
(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=LOCALPORT))
(ADDRESS=(PROTOCOL=tcp)(HOST=REMOTESERVER)(PORT=REMOTEPORT))
(CONNECT_DATA=
(SID=STANDBYSID)
)
)

5)Start the redo transportation in Production.

sqlplus "/as sysdba"
SQL> alter system set log_archive_dest_state_2=enable;
alter system switch logfile;

6)Write a script to monitor and to recreate the tunnel, if it s broken.. Schedule the script to run in cron or daemonize the script..

#!/bin/sh

if test `ps -ef|grep -v grep|grep -c "LOCALPORT:REMOTESERVER:REMOTEPORT"` -eq 0
then
echo "ssh tunnel broken, starting it again"
date
/usr/bin/ssh -f -C -N -L LOCALPORT:REMOTESERVER:REMOTEPORT
fi