Re: RMAN - 11g Full backup Times

From: Jared Still <jkstill_at_gmail.com>
Date: Sat, 19 Mar 2011 11:05:02 -0700
Message-ID: <AANLkTi=4eXFwEtcxprHCTtbbeNGYT5k1=YBFTA_U3tQg_at_mail.gmail.com>



On Thu, Mar 10, 2011 at 9:33 AM, Patty Vonick <patty.vonick_at_returnpath.net>wrote:

>
> Any estimates as to how long an RMAN incremental level-0 (full) backup
> might take to run – say when backed-up to a local mount and/or to an NFS
> mount? Right now, we’re allocating 8 channels.
>
>

No way for me to estimate that, but perhaps I can help you do so.

In 2008 I presented on RMAN performance at Hotsos.

The presentation includes info about some tools that will help you determine how much you can push across the network.

One simple method is to create a tablespace on the same destination for the backups. It's a fairly good determination of how fast it might go.

I would not think allocating 8 channels in this situation would be ideal, unless you have a large disparity between how fast you can pull data from disk, and how fast you can write it to the backup destination.

Ultimately there's only one way to know, and that is to test it.

>
>
> Also – has anyone experienced a significant decrease in RMAN backup I/O
> throughput after upgrading from 10g to 11g – resulting in backups taking
> 2-3x longer than before the upgrade? If so, any suggestions?
>
>

No, I have not experienced that myself.

There are so many moving parts in an enterprise system, you just need to find where that bottleneck is.

You might start with testing the write speed to the backup destination.

What else changed during the upgrade?

Network changes?

Storage changes?

Was the backup schedule changed so that now it runs during a different time?

Have developers/operators/users pile on more batch jobs during the backup window?
(I've seen this one triple backup times)

HTH Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist Oracle Blog: http://jkstill.blogspot.com Home Page: http://jaredstill.com

--
http://www.freelists.org/webpage/oracle-l
Received on Sat Mar 19 2011 - 13:05:02 CDT

Original text of this message