Re: Tuning RMAN backup and recovery
- From: "Limin Guo" <lguo.oracle@xxxxxxxxx>
- To: don@xxxxxxxxx
- Date: Fri, 16 Nov 2007 09:09:56 -0500
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
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
Regards,
Limin Guo.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
