I had to give up compression as it slows restores so much. At UKOUG last year we discussed RMAN best practice - I think it was something Oracle was working on. 2009/4/23 Kenneth Naim <kennaim@xxxxxxxxx> > 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. > > > > Ken > > > > *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto: > oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Tony van Lingen > *Sent:* Wednesday, April 22, 2009 9:16 PM > *To:* robertgfreeman@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx > *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. > > Cheers, > Tony > > 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 > > > > Robert G. Freeman > Author: > 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: http://robertgfreeman.blogspot.com > 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 <JBECKSTROM@xxxxxxxxx> <JBECKSTROM@xxxxxxxxx> > *To:* oracle-l-freelists <oracle-l@xxxxxxxxxxxxx> <oracle-l@xxxxxxxxxxxxx>; > oracle-db-l > <oracle-db-l@xxxxxxxxxxxxxxxxxxxx><oracle-db-l@xxxxxxxxxxxxxxxxxxxx> > *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 > -- Howard A. Latham