Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Tuning RMAN backup and recovery

Re: Tuning RMAN backup and recovery

From: Limin Guo <>
Date: Fri, 16 Nov 2007 09:09:56 -0500
Message-ID: <>


I guess that it is a known issue of compression performance with RMAN in 10.1 and 10.2. That is probably why Oracle 11g has a new compression algorithm, with which the performance of RMAN compression is noticeably faster than in previous releases.

I did a benchmark testing last year in both 10.1 and 10.2 databases in a Solaris box with 16 processors. When compression is enabled (no parallelism), RMAN backup takes about 5 times longer than the one without compression, and the backupsets size is about 5 times smaller. That was the reason I thought the compression option in RMAN in 10.1 and 10.2 is not practical, especially for restore and recovery.

Hope this helps,


On Nov 16, 2007 1:27 AM, Don Seiler <> wrote:
> Some quick answers to these questions before I hop into bed.
> > 1. What version is this..? Are you using a block
> > tracking file for your incrementals? If not you may be
> > backing up way more information than you need too.
> Sorry for not mentioning this straight away. This is Oracle EE
> on RHEL4. Processing is 4 dual-core 64-bit CPUs. Both RDBMS
> and OS are 64-bit.
> Yes we use BCT for incrementals. Our level 1 incrementals take
> anywhere from 30 to 90 minutes. Our schedule is to do a level 0 on
> Saturday evening, and level 1 on all other evenings during the week.
> > 2. Are you doing your parallel backups to the same
> > disk? You could be running into disk contention if so.
> Yes we are (to /rman), and this is my first hunch. Shamefully, I'm
> not well-versed by any means with the storage side of database
> operations. If this Veritas partition were striped across multiple
> disks, does that mean anything in terms of being able to support
> parallel writes? Or should I only think of it as 1 and not try to
> play games?
> > 3. What is your CPU usage during the backup. As
> > mentioned earlier, if you are CPU constrained then
> > compression can slow things down. If you are not CPU
> > constrained then compression can very much speed
> > things up and make your backup images much smaller.
> The load sometimes goes over 21.00. If you're looking for a different
> metric I can try to get that as well.
> Obviously storage space was the reason we use compression here, and
> especially the reason we don't do the incremental merge scenario that
> Job mentioned. Incremental merge does an image copy of all data files
> for the base image. A normal uncompressed backup would at least skip
> whatever empty and/or unused blocks, if I recall correctly.
> I'd like to get a picture of the ideal backup-to-disk scenario with a
> goal of minimizing backup and especially restore/recovery. Should I
> have 4 partitions on physically separate spindles for the 4 parallel
> jobs? Suck it up and do the incremental merge (although I don't see
> that affecting restore/recovery time)? Just not do compression? With
> a recovery window of 7 days it might take up quite a bit more disk (is
> "disk is cheap" still the fashionable response?).
> --
> Don Seiler
> ultimate:
> --


Limin Guo.
Received on Fri Nov 16 2007 - 08:09:56 CST

Original text of this message