> "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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
