Re: Upgrading a standby database - deploying Clone down the pipe

Martin,

I was reading an Oracle Document from Technet on the train ride home tonight -

Oracle 8i Standby Database by Lawrence To 7 June 1999

On page 12 - the article discusses version compatibility between Primary and Standby Databases.
"In some cases" if the compatible setting is is the same in the 2 init<SID>.ora files, different minor versions can be deployed. It does not go into further detail.

If you're going to apply a patch set to a Primary Database - it would be a risk that would have to be tested to not upgrade the binaries on the Standby Database and re-deploy a new clone of the primary.

When I tested the application of the 8.1.6.1.2 patch set - it produced around 540 MB of archived redo logs.

Typically, I get around 85% compression of Oracle files (exports, anyways).
If your database is fairly small, after performing a cold or hot backup (or RMAN backup set), you may be better off to compress the datafiles (+ archived redo logs if hot backup). Pkzip.exe and arj.exe can be called from the command prompt or via a batch file, as can the NT Resource Kit's compress.exe.

Compression of Oracle Datafiles - benchmark - Oracle 8.1.6 Standard - Windows 2000 Pro SP1
WinZip 8.0
Dual PIII 550 256 MB RAM
2 x 4.3 GB Ultra2 Wide SCSI drives - JBOD, shared controller (relatively slow drives)

Source drive - 		C:
destination drive - 	D:
elapsed time -		02:21 minutes
file name - 		system01.dbf

			      bytes         KB           MB
file size 		269,230,080 	262920		256.7		
compressed size  	 73,400,320	 71680		 70.0
compression  /sec	  1,909,433	  1865		  1.82

compression % = 72.7

CPU utilization of around 40 % - or around 400 MHz System datafile was 99.85 % full
 (it should have had the autoextend next size larger)  its just a play database for testing new patch sets - java stuff filled up system.

So - depending upon the tradeoff for bandwidth and computing power, it could be faster to compress the files before sending them down the pipe.

Say for a small sample database of 1.5 GB:

FILE_NAME                 TRUNC(BYTES/1048576)
------------------------- --------------------
DR01.DBF                                    32
TOOLS01.DBF                                 32
RBS01.DBF                                  256
SYSTEM01.DBF                               256
INDEX_DATA01.DBF                           384
USER_DATA01.DBF                            512
                                           ---
                                          1472 MB

Compression time (extrapolated):

1472 MB
----------- = 809 sec = 13.5 minutes to compress. 1.82 MB/sec

Pipeline stats - example site has 1/2 a T1 available for Data - assume that cloning takes place off-peak

              1472 MB                      1472 MB
-------------------------------------  =  -------------  =  15293 sec 
=  254 minutes  =  4.25 hours
      Mb    1 byte                                  MB
 1.54 -- *  ------ * 50 % utilization       0.09625 ---
      sec   8 bits                                  sec

Doesn't look like any further stats are required - 80% compression could cut the transport time to 1 hour.
Compression to move cloned DB to standby looks like a must. Just remember that the you may need to create a batch file to move the datafiles to their correct location on the standby if the compression Received on Tue Oct 17 2000 - 02:10:37 CDT