Re: hosed database

From: Frank van Bortel <frank.van.bortel_at_gmail.com>
Date: Sat, 31 Dec 2005 16:26:21 +0100
Message-ID: <dp67ab$3nn$1@news4.zwoll1.ov.home.nl>

Bruce Coryell wrote:
> Frank van Bortel wrote:
>

>> Bruce Coryell wrote:
>>
>>> I currently use Waters' Millennium HPLC software, which has an embedded
>>> instance of Oracle 8i.  Recently the hard disk crashed, and hosed the
>>> connections between the data files and the database,  so the data is now
>>> inaccessible.  Is there anyway to rebuild the database manually to at
>>> least get the data to a point where it can be retrieved?  (Waters does
>>> not offer this service).
>>
>>
>>
>> As always... depends....
>>
>> Any backups?
>> What do you have? Datafiles, ok - how many?
>> Any control file(s) left?

>
>
> Backups - yes. Is there any way I can use that to access data generated
> after the last backup? However, my lab is very busy, and backing up
> seems to be a half a day process so the last backup is several months old.
>
> What file extensions should I look for to identify control files? (As
> you may have guessed, a total newbie. I'm a chromatographer, not a DBA).

How important is this data?
Worth considering hiring a DBA for a day?

Control files can be named anything, but usually have names like control01.ctl

I cannot imagine a backup half a year old is still valuable; next time reconsider your backup mechanism, especially if it takes half a day. Must be a large db (RMAN creates a backup of 70GB database in about 45 minutes... disk-to-disk).

You mention 8i is embedded - any chance of getting an Oracle sqlplus session to your database (be it recovered or not)?

You first have to backup whatever you have now. I cannot stress this enough: this is all you got, be careful with it!
After you have taken a backup of your disk(s), and verified them, reinstall the software, oracle 8i in particular.

You will then have to recreate the services (assuming Windows), using oradim.exe. If not Windows, set your environment variables as they used to be.

You can then try to connect, using the following: If Windows, make sure you do not need the network: c:\> set oracle_sid=<YOUR SID>
c:\> svrmgrl
SVRMGR> connect internal
Hopefully, you'll get the following:
SVRMGR> Connected to an idle instance.
Then try the following:
SVRMGR> startup nomount
And see if that works...
If no errors occur, do:
SVRMGR> alter database mount;
Again, if no errors occur, time for:
SVRMGR> recover database;
SVRMGR> alter database open;
Hopefully, you are greeted by:
SVRMGR> database opened.

You are back in business! Needless to say, you do want to take a backup (yes, again!) in this stage!

If you see any errors, stop, and copy/paste them - it's not possible to describe all recovery scenarios here.

-- 
Regards,
Frank van Bortel

Top-posting is one way to shut me up...

Received on Sat Dec 31 2005 - 09:26:21 CST