Re: ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:<40ce1f76$0$13622$afc38c87_at_news.optusnet.com.au>...
> "Joel Garry" <joel-garry_at_home.com> wrote in message
> news:91884734.0406141328.329014f5_at_posting.google.com...
> > "Howard J. Rogers" <hjr_at_dizwell.com> wrote in message
> news:<40cd5b12$0$13621$afc38c87_at_news.optusnet.com.au>...
> > > "yls177" <yls177_at_hotmail.com> wrote in message
> > > news:c06e4d68.0406132356.1965d961_at_posting.google.com...
> > > > i add a datafile to my production and did the same with my standby.
> > > > afterwhich, i synch back them but get the below
> > > >
> > > >
> > > > ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get
> > > > error below
> > > > ORA-01194: file 1 needs more recovery to be consistent
> > > > ORA-01110: data file 1: '/oracle/SID/data1/system_1/system.data1'
> > > >
> > > >
> > > > the log sequence in my production and standby servers are the same and
> > > > my archive log list shows the same sequence as well as given further
> > > > confirmation by my alert file.
> > > >
> > > >
> > > > is there any cause for alarm?
> > >
> > > Er, yes.
> > >
> > > We could analyze this really carefully, and um and ahh about how one
> goes
> > > about propagating physical database changes to a standby. But to do
> that, we
> > > might need minor details such as Oracle version and operating system.
> > >
> > > The shorter story is: forget it. The making of a physical alteration to
> your
> > > primary database renders your standby database invalid, such that it
> needs
> > > to be re-created from scratch (one of the major pains-in-the-butt
> regarding
> > > standby databases since time immemorial).
> > >
> > > Regards
> > > HJR
> >
> > WTF?
> http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a76995/standbym.htm#27175
> >
> > Or a misdirection if resizing a datafile:
> >
> http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=123883.1
> >
> > jg
>
>
> Sorry... I accept that it doesn't actually and technically render the thing
> invalid. I was sort-of hinting at that in my first paragraph. What the
> second paragraph was hinting at is that I have generally found relying on Or
> acle's own propagation methods to be fiddly and problematic, and hence I've
> also found it easier and less fraught with grief to re-create the entire
> standby from scratch when dealing with 8 and 8i standby databases (again,
> the original poster made no mention of a version). In other words, it is a
> practical objection, not a theoretical one. But yes, I didn't make that
> clear in the slightest. And indeed upon re-reading it, that distinction is
> not evident at all. It was therefore extremely badly written, rendering it
> less than helpful, and indeed downright misleading. I should have done
> better, so I apologise.
>
> Regards
> HJR
That's what you set yourself up for when giving large amounts of good advice and then one flaky post! :-)

Maybe my experience is skewed, but it seems to me that most standby recreations (of a production system that is big and important enough to require a standby), although easier, take too long. If the whole purpose of the standby is to be able to get the business going in a matter of minutes, and the standby takes hours or days to recreate, the fiddly and problematic stuff (or avoiding a, horrors, resetlogs) becomes the lesser evil. The practical matter is what SLA is expected.  Oracle doesn't prepare customers to be faced with a decision like "do I use these managed recovery features and sometimes have to do strange things like crash the production db, or not use them and have to deal with manual standby administration and the inevitable problems that arise there?" In fact, they'd probably just avoid the question and say "upgrade," as if that will solve everything.

jg

--
@home.com is bogus.
Happy Birthday, Wanda June! 
http://www.signonsandiego.com/uniontrib/20040613/news_1n13enolagay.html