it happened, lost database and recovery catalog. starting distaster recovery research
Ben
had a storm this weekend and power went out to the disk cabinet on our
development machine. I was just informed by our sys admin that we
might be having to recover from disk to get everything back.
Luckily it is just our development machine but we do have critical
data in that database. The recovery catalog was located on the same
machine and filesystem. Now I'm setting forth with the research on how
to get it back. I have documentation of control file backups, the
dbid, and the last hot backup of the database. I don't have a backup
for the recovery catalog that we were using. Correct me if I'm wrong,
but I guess I'll be recovering the control file(s) then recovering the
database from those instead of the catalog. I've practiced recovery in
the past but never without the recovery catalog.
Wish me luck. Any pointers?
Ben
I should add the database was in archivelog mode and we have those as
well. The database was up for about a day without any activity when
it's datafiles were most likely un-accessible.
neil kodner
Have you tried running an RMAN restore without first connecting to any
catalog? The backup information is also stored in the control files.
We've performed restores while bypassing the recovery catalog.
joel garry
The first thing is to backup anything you can, so you don't shoot
yourself in the foot by screwing things up trying to recover.
I'm not real sure what you mean by recover from disk, but in general,
if you can use the control file that Oracle was using during the
crash, you will do better than with one you've recovered. The manuals
and metalink have examples covering many common situations. You may
need to tell rman where things are, one way or another. If you use a
recovered catalog, you may need to use the recover using backup
controlfile syntax to tell Oracle to apply more recent archived logs
(see PITR examples).
Hopefully you've learned some lessons about placement and backup of
your catalog, as well as keeping practiced in recovery.
jg
--
@home.com is bogus.
$230M worth of spam: http://apnews.excite.com/article/20080514/D90L6QC00.html
Ben
>
> - Show quoted text -
Oh, it's going to be interesting to say the least. :)
I meant recover from *tape* instead of disk.
I'm still waiting on word whether or not our admin is going to be able
to get the Oracle home and other non database file areas back. If we
can get the home back, that will give us the spfile, if not then I'll
have to grab it from our last full backup. Then I was planning on
recovering the control file from tape and proceeding with a pitr from
there. The file system that holds our control file isn't part of the
general file system OS backup plan. So I'll have to use the control
file from the previous night's backup. Just curious as to why I would
be better off using a non-recovered control file?
I had already implemented the writing of the dbid to the alert log
every morning just in case I ever needed it, I guess this is going to
be that time where I'll need it.
Frank van Bortel
Which makes sense, as the catalog is no more than
a copy of your control file.
Both of which should be backed up!!!
FvB
Frank van Bortel
> Just curious as to why I would
> be better off using a non-recovered control file?
>
Because it has the latest changes written to it, which
your backed up control file does not. E.g. it knows
it still misses those 13 archived redo log files, due
to log switches *after* the former backup.
FvB