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]
Re: Recover 8.1.7 DB with _allow_resetlogs_corruption
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 - From: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L 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. ApplewhiteDatabase AdministratorAustin Independent School DistrictAustin, Texas512.414.9715 (wk)512.935.5929 (pager)[EMAIL PROTECTED]
Re: Recover 8.1.7 DB with _allow_resetlogs_corruption
Btw, depending on your filesystem HP-UX has an unerase utility called unrm. Which might not help you anymore if you have copied files to your filesystem or some files have extended. Also, when someone deletes a datafile of *open database* on unix - if you don't have a backup then do NOT shut down Oracle. As long as the file remains open (and writable files are always open at least by dbwr), the file contents are there. You could use export or possibly even RMAN to backup your data. Tanel. - Original Message - From: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L 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. ApplewhiteDatabase AdministratorAustin Independent School DistrictAustin, Texas512.414.9715 (wk)512.935.5929 (pager)[EMAIL PROTECTED]
Re: Recover 8.1.7 DB with _allow_resetlogs_corruption
That trick with "still-open" files (don't
shutdown) does not appear to be an option anymore in this case.
As for those _parameters, they could force the
instance to start, but you are likely to have questionable data somewhere - not
something tolerated in a "Financials" application, I would suspect.
Your best (only?) bet would be to go back to the
last full backup, and do a cancel-based recovery, and hoping that your hot
backup included the last archive log containing end-hot-backup
marker.
- Original Message -
From:
Tanel
Poder
To: Multiple recipients of list ORACLE-L
Sent: Sunday, August 24, 2003 12:14
AM
Subject: Re: Recover 8.1.7 DB with
_allow_resetlogs_corruption
Btw, depending on your filesystem HP-UX has an
unerase utility called unrm. Which might not help you anymore if you have
copied files to your filesystem or some files have extended.
Also, when someone deletes a datafile of
*open database* on unix - if you don't have a backup then do NOT shut
down Oracle. As long as the file remains open (and writable files are always
open at least by dbwr), the file contents are there. You could use export or
possibly even RMAN to backup your data.
Tanel.
- Original Message -
From:
[EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L
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.
ApplewhiteDatabase AdministratorAustin Independent School
DistrictAustin, Texas512.414.9715 (wk)512.935.5929
(pager)[EMAIL PROTECTED]
