Re: Standby recovery

"Tanel Poder" <change_to_my_first_name_at_integrid.info> wrote in message news:<3f549b2e$1_1_at_news.estpak.ee>...
> 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.)
>

/home2/oracle$ sqlplus /nolog

SQL*Plus: Release 8.1.7.0.0 - Production on Tue Sep 2 16:34:00 2003

(c) Copyright 2000 Oracle Corporation. All rights reserved.

SQL> connect internal/soyathinkidunnoaboutinternal Connected.
SQL> recover managed standby database;

ORA-00283: recovery session canceled due to errors
ORA-01124: cannot recover data file 1 - file is in use or recovery
ORA-01110: data file 1: '/oradata/SXXXX/system01.dbf'

SQL> And in alertlog:

Media Recovery Waiting for thread 1 seq# 42 Tue Sep 2 16:34:17 2003
ALTER DATABASE RECOVER managed standby database Tue Sep 2 16:34:17 2003
Media Recovery Start: Managed Standby Recovery Media Recovery failed with error 1124
ORA-283 signalled during: ALTER DATABASE RECOVER managed standby database ...

Which of course doesn't quite show whether you have blown off the original managed recovery and have to manually fix it. It takes up to 5 minutes after switching logs on the source box to archive the next log on the standby box to show it is still working (fast ethernet network, standby db only thing on 4 processor hp-ux, faster source box barely used at this time of day).

Blame it all on Autoraid, I guess.

> 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
> >
> >

jg

--
@home.com is bogus.
http://www.pbs.org/cringely/pulpit/pulpit20030828.html