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@xxxxxxxxx> 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


Other related posts: