Re: RMAN Restore Archivelog Files -- Very Slow

From: Jared Still <jkstill_at_gmail.com>
Date: Thu, 5 Feb 2009 09:32:31 -0800
Message-ID: <bf46380902050932m55e4956eu953eb39f554685e6_at_mail.gmail.com>

You may want to search the Oracle-L archives at freelists.org for RMAN performance problems.

This has appeared fairly frequently of late.

One of the posts lists a MetaLink note that is actually a master list pointing to other notes, all relating to RMAN performance problems.

BTW, the 'fix' for many RMAN performance problems:

  SQL 'ALTER SESSION SET OPTIMIZER_MODE=RULE' Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist

On Wed, Feb 4, 2009 at 9:42 PM, <rama.ari_at_accenture.com> wrote:

> Thanks for reading this email & Thanks in Advance for your help.
>
>
>
> We are facing performance issue when trying to restore archive log files
> using RMAN catalog.
>
>
>
> Environment:
>
> Oracle Database: 10g (10.2.0.3) RAC
>
> Database Size: ~350 GB
>
> Archive Log Files per day: ~30 – 45
>
> Archive Log File Size: 200MB
>
> NetBackup: 6.5
>
> Backups: RMAN to VTL (Weekly Full, Daily Incremental)
>
>
>
> We restored 350 GB of database using RMAN catalog and it took around 6 Hrs
> which is very good. Most of the datafile sizes are around 30GB and some of
> the files are couple of GB.
>
>
>
> When we try to restore archive log (200MB) files using RMAN Catalog and it
> is taking approximately 15 Minutes for each file. If we bypass RMAN catalog
> by using backup information from controlfile, it takes approximately 2.5
> Minutes to restore each archive log file. After working with backup team, we
> found out that approximately 12 Minutes time was spent for the hand shake
> between RMAN Catalog and Netbackup catalog.
>
>
>
> Did anyone of you have seen similar situation and what might be the
> problem? Have you done any kind of database maintenance work for RMAN
> repository database to improve performance?
>
>
>
> Thanks,
>
> *Rama*
>
>
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you have
> received it in error, please notify the sender immediately and delete the
> original. Any other use of the email by you is prohibited.
>

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

Received on Thu Feb 05 2009 - 11:32:31 CST