| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Missing all redo log files
I had a similar problem. Maybe not quite as bad as yours. I thought all
was lost until I squeezed Oracle for the following fix. It worked no
problem - but be aware of the pitfalls. Here it is:
for you. If you haven't already done so, take a backup of what you have now in case
you need to try these steps again.
First let's try to fake recovery:
SET ORACLE_SID=<sid>
SQLDBA71 (this was a version 7.1 database - but everything should still work. - use the current Server Manager)
CONNECT INTERNAL/password
STARTUP MOUNT RESTRICT RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE; (You may have to issue a Create ContolFile command first)
when prompted for the first archived redo log, type CANCEL and press
<Enter>
ALTER DATABASE OPEN RESETLOGS; This may work if the only reason we were flagging media recovery was because
the control file was recreated.
WARNING: READ ALL OF THE FOLLOWING BEFORE PROCEEDING
If you have lost the current redo logs as well as your archive logs, and you
must salvage your data (i.e. a production system) then to force the database
to open, we must corrupt the database.
The consequences of using these parameters is that they will corrupt the
database and you will be required to rebuild your database, via
export/import.
In addition, there may be "logical" corruption as all transactions on disk
will
be treated as committed, as there are no redo logs to rebuild the rollback
segments to roll back uncommitted transactions.
After reading and understanding the consequences of the above warnings, do
the
following to force the database open:
_ALLOW_RESETLOGS_CORRUPTION=TRUE _CORRUPTED_ROLLBACK_SEGMENTS= <list of all your rollback segments,
separated by commas>
3. Comment out the ROLLBACK_SEGMENTS parameter, if one exists
4. Startup mount the database in restricted mode
STARTUP MOUNT RESTRICT 5. Fake recovery
RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE; when prompted for the first archived redo log, type CANCEL and
press <Enter>
ALTER DATABASE OPEN RESETLOGS;
the errors produced in more detail. If this succeeds,
proceed to step 6.
9. REBUILD the database by taking a full database export, and then
importing into a new database.
parameters, the database is NOT useable. The sole purpose is to get the
database open so you can do a full database export and recreate it. DO NOT
ATTEMPT TO DO ANYTHING OTHER THAN A FULL DATABASE EXPORT. Solution Explanation:
The reason we need to force the database open is to bypass instance recovery
because we no longer have the information available. Bypassing instance
recovery means we will not roll forward any data from the current online
redo
log AND we will not roll back any uncommitted transactions. The result of
this is a database containing inconsistent data. The customer will have to
determine the impact of this inconsistency to their data - we cannot provide
any assistance in this area. The rebuild is required to resolve any
potential
inconsistency in the data dictionary.
Alianto <alianto_at_mincom.co.id> wrote in message
news:36a2e10c.0_at_news1.ibm.net...
>Our clients use HP Oracle database, when database is running, one without
>accident delete all redo log files and oracle's system shutdown
>automatically without any messages. When One try to startup the instance,
it
>show a message :
>
>SVRMGR> startup
>ORACLE instance started.
>Total System Global Area 34165080 bytes
>Fixed Size 47936 bytes
>Variable Size 13080088 bytes
>Database Buffers 20971520 bytes
>Redo Buffers 65536 bytes
>Database mounted.
>ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
>SVRMGR>
>SVRMGR> alter database open resetlogs;
>alter database open resetlogs
>*
>ORA-01194: file 1 needs more recovery to be consistent
>ORA-01110: data file 1: '/data2/mims13s/dbs/system.dbf'
>SVRMGR>
>
>Regards,
>
>Alianto
>
>
Received on Mon Jan 18 1999 - 08:12:17 CST
 |
 |