RE: Tuning RMAN backup and recovery

Your Sun tests are in direct opposition to my own real life production experiences. Of course, many things might impact such testing, but in *many* cases I've found compression in 10g RMAN to make for much faster backups. Not always, but often.

RF

Robert G. Freeman
Oracle Consultant/DBA/Author
Principal Engineer/Team Manager
The Church of Jesus Christ of Latter-Day Saints Father of Five, Husband of One,
Author of various geeky computer titles
from Osborne/McGraw Hill (Oracle Press)
Oracle Database 11g New Features Now Available for Pre-sales on Amazon.com! BLOG: http://robertgfreeman.blogspot.com/ Sig V1.2

-----Original Message-----
From: Limin Guo [mailto:lguo.oracle_at_gmail.com] Sent: Friday, November 16, 2007 7:10 AM
To: don_at_seiler.us
Cc: Robert Freeman; Oracle-L Freelists
Subject: Re: Tuning RMAN backup and recovery

Don,

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,

Limin.

On Nov 16, 2007 1:27 AM, Don Seiler <don_at_seiler.us> 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
> 10.2.0.2 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
> http://seilerwerks.wordpress.com
> ultimate: http://www.mufc.us
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
Regards,

Limin Guo.

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