Re: Standby recovery

You're throttled by the fact that parallelization of log apply is only done on the write. There's still only one managed recovery process *reading* the redo, and that isn't alterable, from memory.

So if you've already parallelized the recovery process, that's about as far as you can take it.

On the other hand, if you've got 8 CPUs, then I'd suggest you increase the degree of parallelization to (maybe) 16, though it really rather depends on the number and layout of the data files as to whether that will help at all. But I'd certainly give it a go. Usual advice, as far as I remember it, is two or three recovery processes per datafile.

Regards
HJR "Goran D." <goran99_makni_at_yahoo.com> wrote in message news:bj20ac$db2$1_at_fegnews.vip.hr...
>
> Hello,
>
> This is actually a general question, although it regards to a specific
> database.
> We have a physical standby database for a production database (8.1.7.4.0)
at
> another location; the managed recovery and automatic archiving take place
> without problems.
> However, we noticed that recovery of a single arch.log is rather slow -
the
> machines (8 CPU HP-UX) and storage boxes (EMCs) are the same.
> During periods of peak activity , the production database takes about a
> minute to generate a single redolog of 1GB; after it is transferred to
> standby machine, standby database needs (average) 3-5 minutes to apply
this
> particular log.
>
> We tried to establish parallel managed recovery (8 processes), but gained
> improvement of only 10-20%.
>
> This still represents no serious problem, as the time during the day is
> still sufficient to apply all the logs. However, if activity of the
> production database increases, we fear that standby would not be capable
of
> performing the recovery - ie that the production would generate more logs
> during the day that the standby is capable of applying.
>
> I have to emphasize that this is not the matter of network transport
(which
> is satisfactory), rather the speed of applying logs during recovery.
>
> So is there a way to speed-up the recovery process..? Any suggestions
> welcome.
>
> Regards,
> Goran Dokmanovic
> Oracle DBA
> VIPNet d.o.o
>
>
Received on Tue Sep 02 2003 - 07:04:16 CDT