RE: compressed backup - is this a reasonable size

From: Crisler, Jon <>
Date: Fri, 24 Apr 2009 12:15:12 -0400
Message-ID: <56211FD5795F8346A0719FEBC0DB0675042C7B7C_at_mds3aex08.USIEXCHANGE.COM>

RMAN compression is very CPU intensive. The trick to get both compression and short backup times is to use multiple disk streams and multiple CPU's. I typically use 4 to 8 streams, and have used as many as 48 streams. Also, some CPU's have poor floating point units which translates into poor compression performance (very high cpu when compression is used). Sun systems based on T1 and T2 cpu's fall into this category.

Compression has a good effect in that it reduces disk i/o loads for writes, at the expense of higher cpu usage. Compression results are directly affected by the type of data- I have a system in which 80% of the database is LOB's and compresses poorly, but I still have to use compression to save disk space, and cpu usage is sky high. I have another db with 500gb that takes 30 min uncompressed but 60 min compressed- disk usage is only 15% of uncompressed size.  

[] 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 Fri Apr 24 2009 - 11:15:12 CDT

Original text of this message