Re: Database Down

> "Burton, Laura L." wrote:
>
> I have an Oracle 8.0.5 database residing on a Windows NT operating
> system which uses Raid5. The 'almost never' has happened; two disks
> have gone bad at the same time. As fate would have it the 'complete'
> physical backup performed the day before the disks crashed (Friday,
> May 18) cancelled. Of course this happened on Saturday on a weekend
> in which I was out of town and did not get back in until late this
> afternoon.
>
> My system admin said he restored the drives on the bad disks from a
> physical backup created the previous Friday (May 11) and then restored
> the differential backup from this past Thursday (May 17). The Archive
> files were also on one of the disk that went bad. I have looked at
> the alert log and the hot backup executed on the Thursday prior to the
> Saturday crash completed successfully. Something that does not seem
> right, and I'll talk with my system admin tomorrow, is that when I
> looked at the datafiles and archive logs he restored they were all
> dated May 11, the date of the complete backup. If he applied the
> differential as he said, does this not add the archive logs written
> from May 11 through the May 17 differential backup? According to the
> alert log it looks like I am missing approximately 438 logs.
>
> I thought I would have to restore all datafiles and archive logs from
> the physical backup so that they would be in sync, and then 'recover'
> the database using the hot backup. This would only incur minimum data
> loss since Saturday is a non-work day for most employees. After
> reading the Backup and Recovery manual it looks like all I have to do
> is 'recover' the database using the hot backup. Wouldn't it matter
> that the datafiles would not currently be in sync since the datafiles
> on the disk which did not crash were ok and not restored? Since the
> hot backup would restore all the datafiles I would think it wouldn't
> matter. Correct??
>
> I would appreciate some second and third opinions. This is my first
> 'live' recovery and I want to make sure as much as possible that I do
> what will have the least impact on data loss. It goes without saying,
> but I will have a complete backup of the 'good' disks before I tackle
> this beast.
>
> Thank you in advance,
> Laura

0. caffeine.

1. (you already know this) your latest archived redo log is what you will be able to recover the database to - nothing further. I assume that a budget for duplexed archived redo logs will be forthcoming. Network Attached Storage is possibly an even better solution - with scheduled jobs to propagate archived logs to the NAS box.
2. You *will* be performing incomplete recovery. Recover until cancel, preferably with a backup controlfile. Did you create a backup controlfile as part of the hot backup on May 11th? Restore with that controlfile.
3. After the recovery is completed (you've opened RESETLOGS) close the database and get a *full* cold backup. Fight the urge to *get the database open* when you don't have anything to intiate your next recovery from. You don't want to have to repeat this entire processes *ever* again.
4. Possibly, you want to have the SysAdmin restore the thursday night archived redo logs (17th) to a different folder than the previous backup set (11th). This may be the reason why the later set of archived redologs is not appearing.
5. If you have more recent copies of datafiles than the May 11th backup set - move them to a different directory - and restore the entire hot backup set. Recovery will attempt to recover all datafiles to be in-sync at a specific SCN#. To have some datafiles ahead of that SCN could cause more problems. If you were attempting complete recovery - I would recommend otherwise. If you force the database open in an inconsistent manner, you'll have to export and rebuild (your last option - next to the data unloader).

>From the Oracle 8i Backup and Recovery Handbook
pg 263

"Regardless of the method used, the fundemental concept of recovery is very straightforward: Before opening the database, all data files must be recovered to the exact same point in time and not have any changes in the future from this point."

As Rachel C. would say - Don't Panic!

Best of luck,

Paul

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Paul Drake
  INET: paled_at_home.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).