Re: suspicious standard Oracle Linux start/stop script

"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