Re: compressed backup - is this a reasonable size

I agree 100%, the answer is very much it depends. So many different variables to consider. One thing I've found is that we DBA's tend to discount something if it does not work, assuming that it "does not work" rather than finding out why it does not work (fairly, we often are short on time). Sometimes there is just a minor tweak required, sometimes it just does not work. :-) I've seen compression decrease backup times, I've seen it increase them. Same with restores. It would be nice to compile a large set of before/after numbers and see what the average experience is. :-)

Cheers all!

RF




 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: Kenneth Naim <kennaim_at_gmail.com>
To: tony_vanlingen_at_technologyonecorp.com; robertgfreeman_at_yahoo.com; oracle-l_at_freelists.org
Sent: Thursday, April 23, 2009 1:31:42 AM
Subject: 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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Tony van Lingen
Sent: Wednesday, April 22, 2009 9:16 PM
To: robertgfreeman_at_yahoo.com; oracle-l_at_freelists.org
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_at_gcrta.org>
To: oracle-l-freelists <oracle-l_at_freelists.org>;
oracle-db-l <oracle-db-l_at_Groups.ITtoolbox.com>
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

--
http://www.freelists.org/webpage/oracle-l