RE: compressed backup - is this a reasonable size

From: Kenneth Naim <>
Date: Thu, 23 Apr 2009 03:31:42 -0400
Message-ID: <039101c9c3e5$8d2f3c60$a78db520$_at_com>

As in all situations it depends; it depends on how many channels are being used, how fast the cpu's are, what media the backup is going too, how many tape/disk drive are being read from and to, the speed and type of the network between all the points, and the amount of work happening while the backup is running. As a broad generalization slow cpu's with one or few channels and a fast IO subsystem will result in a slower backup when compression is added or in other words if CPU is the bottleneck in your backup, compression is not recommended.  

I did an analysis of my clients backup system, where political fingers were being pointed in every direction and each piece of the system was believed to be at fault by a different group. A 6+tb 10gr2 database was being backed up from 150 drive raid 0+1 SAN to a 3 drive tape library system using 24 channels connected via gigabit Ethernet on 12 cpu/24 core Sun 2900. By reviewing the data in the V$BACKUP_SYNC_IO and V$BACKUP_ASYNC_IO views I proved that the bottleneck was on the gigabit network, and that the san was barely being touched. Due to the politics several components were changed simultaneously, the Ethernet to tape was replaced with a single channel 2gb fiber to 160 disk ibm xiv array disk and compression was added. Performance went from 18 hours to under 5. The single fiber card is our new bottleneck and performance should improve once our os team, sun and ibm figure out why the second card is not playing nice.  


From: [] On Behalf Of Tony van Lingen
Sent: Wednesday, April 22, 2009 9:16 PM
To:; Subject: Re: compressed backup - is this a reasonable size  

That is interesting. I was just discussing this with my collegue who specialises in RMAN backups. He asserts exactly the opposite where it comes to backup times. As an example, we have an GIS database of about 1TB (10g) which backs up in 30 mins in standard mode. When he enables compression it takes up to 6 hours and is very cpu intensive. Apart from that, he agrees that the compression is quite good.

Apparently the compression also should not be used in combination with a compressed tape device.


Robert Freeman wrote:

Very reasonable. Compression can do wonders for the size of backup sets! It can also significantly improve overall backup times. What were your times for the backup compressed and non-compressed and how much of a difference in CPU did they make.

Be aware that someone on here mentioned a bug with compression just a few days ago.I looked in Metalink for compression related bugs and found a few. In a very quick looksee I find most the bugs seem to be related to backups as opposed to restores. So it seems if you can get a good backup, then you might well be ok. As always, test test test, your restores. No piece of software is perfect! :-) On a regular basis continue to test your restores just in case a bug creeps in. My personal experience with Compression has been very positive.


Robert G. Freeman
OCP: Oracle Database 11g Administrator Certified Professional Study Guide (Sybex)
Oracle Database 11g New Features (Oracle Press) Portable DBA: Oracle (Oracle Press)
Oracle Database 10g New Features (Oracle Press) Oracle9i RMAN Backup and Recovery (Oracle Press) Oracle9i New Features (Oracle Press)
Other various titles out of print now... Blog: The LDS Church is looking for DBA's. You do have to be a Church member in good standing. A lot of kind people write me, concerned I may be breaking the law by saying you have to be a Church member. It's legal I promise! :-)    

From: Jeffrey Beckstrom <>

To: oracle-l-freelists <>
<>; oracle-db-l
<> <>
Sent: Wednesday, April 22, 2009 7:36:52 AM Subject: compressed backup - is this a reasonable size

Just ran the following command. This is our first RMAN backup. It backed up a 17G database into about 3G of files. Is this reasonable?????  

backup as compressed backupset database plus archivelog delete input;  

Backup states it finished normally.  

Jeffrey Beckstrom
Database Administrator
Greater Cleveland Regional Transit Authority 1240 W. 6th Street
Cleveland, Ohio 44113

Received on Thu Apr 23 2009 - 02:31:42 CDT

Original text of this message