Re: Standby recovery

Hi!

Recovery is IO, not CPU intensive, thus recovery "scalability" depends a lot of your IO subsystem. If you are using async IO, then the gain from parallel recovery will probably be lower than with sync IO.

Btw, in normal recovery scenario you could open several sessions, where you issue serial recovery on different sets of datafiles, that way redologs are read for each session and redo is applied serially, passing the parallel execution messaging mechanism. This can help on platforms where PX doesn't work well - Linux from my experience.
(I'm not sure whether it's possible to do it in stanby recovery mode.)

Tanel.

"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 - 08:28:59 CDT