How many of these refer to instance recovery rather than media recovery?
--
Niall Litchfield
Oracle DBA
Audit Commission UK
*****************************************
Please include version and platform
and SQL where applicable
It makes life easier and increases the
likelihood of a good answer
******************************************
"Joel Garry" <joel-garry_at_home.com> wrote in message
news:91884734.0305301426.6a17e1e8_at_posting.google.com...
> "Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message
news:<3ed74ffe$0$30223$afc38c87_at_news.optusnet.com.au>...
> > "Hans Forbrich" <forbrich_at_telusplanet.net> wrote in message
> > news:3ED66E01.7FF45C70_at_telusplanet.net...
> > > Sybrand Bakker wrote:
> > >
> > > > On Thu, 29 May 2003 16:42:21 +0100, "Niall Litchfield"
> > > > <n-litchfield_at_audit-commission.gov.uk> wrote:
> > > >
> > > > >My advice
> > > > >
> > > > >modify the dbshut sql script so it does a shutdown abort. Oracle
will
> > > > >recover on startup.
> > > > >
> > > >
> > > >
AAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
> > > >
> > > > Seems like we need a competition for the most stupid advice offered.
> > > > There have been quite many the last few days.
> > > >
> > > > Sybrand Bakker, Senior Oracle DBA
> > >
> > > Sure would be nice if we got some consistency going here ...last week
I
> > > got a severe talking to in this list about saying shutdown abort is a
> > > no-no.
> >
> > I hope it wasn't that severe.
> >
> > The facts are: if your current redo log is safe (multiplexing, anyone?),
> > then shutdown abort is no worse than shutdown immediate, which every DBA
> > seems willing to do at a drop of a hat.
> >
> > Anyone going 'Arrrrgggggg' needs to explain why Oracle would be prone to
> > losing data in the event of a shutdown abort, but not with a shutdown
> > immediate.
>
> They're called bugs and implementation issues, which you of course
> refuse to admit the existence or importance of, in the face of plenty
> of metalink evidence. And of course, the "if your current redo log is
> safe" is a huge Achille's heel.
>
> Recovery
> 9203 2645378+ LOB data corruption after RECOVERY
> 9203 2388569 Hang possible in parallel transaction recovery
> 9203 2399093 ORA-16000 opening database READ ONLY
> 9203 2408817 V$RECOVERY_PROCESS.SOFAR may decrease during media
> recovery
> 9203 2424490 OPTIONAL LOG_ARCHIVE_DEST_X failures not written to
> ALERT LOG
> 9203 2449124 MAX_FAILURE in LOG_ARCHIVE_DEST_N does not work
> 9203 2555509 Parallel media recovery slower than needed
> 9203 2594513 ORA-7445 [kcrradinit] possible during ARCH
> cross-instance archival
> 9203 2605511 OERI[3672] changing tablespace READ-WRITE after
> incomplete recovery
> 9203 2662180 RECOVER UNTIL SCN may stop before expected SCN if log
> corrupt
> 9202 2487487 LGWR may hang writing to >1 archive destinations with
> NOAFFIRM
>
> And those are just the ones found and admitted to and fixed for 9.2.
>
> >
> > But it's precisely this sort of "inconsistency" that persuades me it's a
> > waste of time posting here. So I won't be doing so in future. If that
means
> > you don't feel you've been spoken to severely in future, then I guess
that's
> > some kind of bonus.
>
> It's a big internet. I'm sure you can refrain from posting
> anywhere... NOT.
>
> It's not a waste to post here if one understands the purpose of usenet
> newsgroups.
>
> >
> > Cheerio, group: last post!
>
> Buh-bye!
>
> >
> > Regards
> > HJR
>
> jg
> --
> @home.com is bogus.
> Jeez, even MS and AOL kissee and make up!
> http://www.signonsandiego.com/news/uniontrib/fri/news/news_1n30aol.html
Received on Sat May 31 2003 - 16:32:20 CDT
