RE: compressed backup - is this a reasonable size

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  <mailto:JBECKSTROM@xxxxxxxxx>
<JBECKSTROM@xxxxxxxxx>
To: oracle-l-freelists  <mailto:oracle-l@xxxxxxxxxxxxx>
<oracle-l@xxxxxxxxxxxxx>; oracle-db-l
<mailto: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

Other related posts: