Re: RMAN Restore Archivelog Files -- Very Slow

From: Stefan Knecht <knecht.stefan_at_gmail.com>
Date: Sat, 7 Feb 2009 11:04:39 +0100
Message-ID: <486b2b610902070204o45e7add7ya488ffd4034b29b0_at_mail.gmail.com>

You can see where RMAN is spending its time by enabling debug mode as such:

run {
debug on;
restore archivelog .....;
}

Have you ever performed maintenance jobs (crosscheck, delete expired, delete obsolete) ?

Stefan

---

Stefan P Knecht
CEO & Founder
s_at_10046.ch

10046 Consulting GmbH
Schwarzackerstrasse 29
CH-8304 Wallisellen
Switzerland

Phone +41-(0)8400-10046
Cell +41 (0) 79 571 36 27
info_at_10046.ch
http://www.10046.ch

---

On Thu, Feb 5, 2009 at 6:42 AM, <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 Sat Feb 07 2009 - 04:04:39 CST