|
Hi!
You could try to set _corrupt_blocks_on_stuck_recovery to a big value. It sets the number
of unrecoverable blocks to corrupt during recovery.
If it
works, then you'll have a lot of corrupted blocks in your database, you
have to use event 10231 or dbms_repair to skip the corrupt blocks in the table
when exporting or copying data away.
Tanel.
----- Original Message -----
Sent: Saturday, August 23, 2003 9:04
AM
Subject: Recover 8.1.7 DB with
_allow_resetlogs_corruption
8.1.7.0 on HP-UX.
Another DBA (really, it wasn't me) forgot
which server he was on and deleted the RBS tablespace datafile and all the
archived redo logs - on different mount points - of our Production Financials
database. No time for the whys of that story or why we don't mirror our
archived redo logs (which we will do starting today!).
We dug up references to these undocumented
parameters:
_allow_resetlogs_corruption
_corrupted_rollback_segments
_offline_rollback_segments
We have all the current database datafiles (plus the
hot backup RBS datafile from last night), online redo logs, control files,
etc. and have included those undocumented parameters in our init.ora. A
message in the alert log looks hopeful when we attempt to Open
Resetlogs:
RESETLOGS is being done
without consistancy checks. This may result
in a corrupted database. The database should be recreated.
RESETLOGS after incomplete recovery UNTIL
CHANGE 4806846187
However, all our
attempts to open the database have failed with various errors:
ORA-00600: internal error
code, arguments: [4000], [25], [], [], [], [], [], []
ORA-704 signalled during: alter database
open resetlogs
ORA-1139 signalled during: alter database open resetlogs
We also tried to recreate the
control files from a trace coltrolfile, but get this error in the alert log.
On the screen it's a "snapshot too old" error, referring to a rollback
segment with no number or name.
ORA-604 signalled during: ALTER DATABASE OPEN
ResetLogs
Are we hopelessly hosed?
We backed up the database, unfortunately only _after_ we tried a couple
of recovery attempts. Have we messed around with these datafiles too
much and need to restore from our backup? Did our messing with the
database before we backed it up eliminate the possibility of any kind of
recovery, even using those undocumented parameters? Remember, ALL our
archived redo logs between last night's hot backup and today's fiasco are
gone, and there were enough log switches to have cycled through the online
redo logs several times.
We're
logging a tar with Oracle Support, but any advice would be helpful.
Thanks.
Jack C. Applewhite
Database Administrator
Austin Independent
School District
Austin, Texas
512.414.9715 (wk)
512.935.5929
(pager)
[EMAIL PROTECTED]
|
