Re: Recovery performance of standby databases

From: sybrandb <sybrandb_at_gmail.com>
Date: 7 Dec 2006 07:37:26 -0800
Message-ID: <1165505846.395524.203770@73g2000cwn.googlegroups.com>

On Dec 7, 4:29 pm, Chloe C <c..._at_mcrowdd.plus.com> wrote:
> Hi
>
> Does anyone have an idea as to why managed recovery would be
> significantly quicker than 'ordinary' recovery of a 9.2 standby
> database? I've really noticed it this week as I try to catch-up a
> standby database following a 2-week outage from hardware failure.
>
> The SQL statements are:-
> Managed:-
>
> ALTER DATABASE
> RECOVER MANAGED STANDBY DATABASE
> DISCONNECT FROM SESSION
>
> Ordinary:-
>
> RECOVER AUTOMATIC STANDBY DATABASE PARALLEL
>
> I can't imagine that using ALTER DATABASE and DISCONNECT FROM SESSION
> would make a lot of difference, and the PARALLEL clause was intended
> to make things faster.
>
> All I can think of is that normally the log file is scanned prior to
> the update beng applied and this is done during log shipping for
> managed recovery - but this is pure guesswork.
>
> Does anyone have any configuration tweaks for improving recovery
> performance in this sitiuation? There doesn't seem to be a lot of
> information in the manuals

Why do you want to 'tweak' automatic recovery, if managed recovery does the job, and is fast enough, and obtains the same result? Basically (and following the docs), you can go directly to managed recovery, as the FAL process will identify and resolve any archive gaps.
Also the parallel clause applies to managed recovery as well. There is an article up on Metalink which recommends:

- unconfigure the keep cache and the recycle cache
- reduce the shared pool size
- increase the db_cache_size

(Make sure you have a separate spfile handy, once you need to fail over)
- use the parallel clause of the managed recovery statement. And this is all there is to it.

-- 
Sybrand Bakker
Senior Oracle DBA

Received on Thu Dec 07 2006 - 09:37:26 CST