Re: URGENT: ORA-01554 upon startup

andreyNSPAM_at_bookexchange.net (NetComrade) wrote in message news:<3e788b8b.1981944635_at_nyc.news.speakeasy.net>...
> On 18 Mar 2003 17:25:19 -0800, joel-garry_at_home.com (Joel Garry) wrote:
>
>
> >Is there a reason you can't recover the db until the sequence before
> >the one that crashed?
>
> heh.. backups are only exports.. our hardware design calls for no data
> loss (mirrors, dual controllers, dual paths to drives, etc, etc). We
> didn't anticipate a database not to open. this is only a second data
> loss we've had in 4 years (first was due to a serious hardware
> failure, veritas failing to recover, and not having the knowledge in
> house how to rebuild VM volumes manually).
>

LOL! Here I was, wondering whether the transaction slots were in fet$ or something, so I could say whether LMT's could have helped you or if you were TSOL because you had a 20 hour transaction and had "crashed without even knowing it." When all the time it's basic DBA stuff! I've seen plain ol' PC's not fail for 4 years... and hardware designs like yours fail immediately. And Veritas get confused by a bogus controller and do the wrong thing.

What you've got is kinda like having the safest Volvo airbag system and sitting on top of the buckled 3-point seatbelt.

> We were able to recover some of the data from application logs, but
> this was still very painful, the data was fairly valuable.
> Fortunately, we had some redundant data in another db, and were able
> to identify users affected.
>
> Anyway, time to take a second look at our backup strategy.

Yes, Oracle does say in so many words that exports are not sufficient backups. You need to explicate your recovery requirements (which means put an explicit dollar value on your data and uptime), then design a backup strategy to fit. With a DBA.

> .......
> We use Oracle 8.1.7.4 on Solaris 2.7 boxes
> remove NSPAM to email

jg

--
@home.com is bogus.
http://www.signonsandiego.com/news/uniontrib/tue/business/news_1b18gateway.html