Re: compressed backup - is this a reasonable size

From: Howard Latham <howard.latham_at_gmail.com>
Date: Thu, 23 Apr 2009 10:34:48 +0100
Message-ID: <713d96d10904230234j13408ec2ga248ecfa1495051e_at_mail.gmail.com>



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_at_gmail.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.
>
>
>
> 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> <JBECKSTROM_at_gcrta.org>
> *To:* oracle-l-freelists <oracle-l_at_freelists.org> <oracle-l_at_freelists.org>;
> oracle-db-l <oracle-db-l_at_Groups.ITtoolbox.com><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
>

-- 
Howard A. Latham

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Apr 23 2009 - 04:34:48 CDT

Original text of this message