Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

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

Re: Tuning RMAN backup and recovery

From: Don Seiler <don_at_seiler.us>
Date: Fri, 16 Nov 2007 00:27:23 -0600
Message-ID: <716f7a630711152227v7f1dbe4el96faf70e9f20a8de@mail.gmail.com>


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
Received on Fri Nov 16 2007 - 00:27:23 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US