Some things that I've found to recover database without redo

SQL> startup mount
SQL> recover database until
SQL> alter database open resetlogs;

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [2662], [0], [25501152], [0],
[25521272], [12583040], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [2662], [0], [25501151], [0],
[25521272], [12583040], [], [], [], [], [], []
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2662], [0], [25501149], [0],
[25521272], [12583040], [], [], [], [], [], []
Process ID: 10846
Session ID: 1 Serial number: 5

_allow_resetlogs_corruption=true



------------OR


1. shutdown immediate;
2. backup all
3. startup mount;
4. alter session set events '10015 trace name adjust_scn level 1';
5. alter database open;

------------OR

alter session set events '10015 trace name adjust_scn level 1';

Subject: How to Force the Database Open
Creation Date: 12-OCT-1999
There are times when it may become necessary to force a database open. This
document identifies one way to attempt to get the database open.

You may need to use this procedure because something happened to the database
that required you to perform recovery. The recovery completed, but you receive
the following error message:

ORA-01194 - file 1 needs more media recovery to be consistent

You have determined that there is nothing else that can be done to get the
database to a consistent state. You tried opening the database using
RESETLOGS, but that also failed.


Procedure:
==========

To ATTEMPT to force the database open, perform the following steps:

1. Add the parameter _ALLOW_RESETLOGS_CORRUPTION = TRUE to the init.ora file

2. STARTUP MOUNT the database

3. Issue the appropriate RECOVER DATABASE command:

a) RECOVER DATABASE UNTIL CANCEL

or

b) RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL

4. Enter CANCEL to cancel recovery - there are NO archive logs applied.

5. Enter ALTER DATABASE OPEN RESETLOGS

6. Try selecting from a table - for example, SELECT SYSDATE FROM DUAL

If you get a row back, the database is open and "functional" - you
could try to select from a couple of other tables just to make sure.
If the instance crashed, check for trace files in the background dump
destination. If you find a trace file, check to see if the trace file
has an ORA-00600 [2662] error in it - this may also show up in the
alert.log file. If this is true, then perform the following steps:

7. SHUTDOWN ABORT

8. STARTUP MOUNT

9. ALTER SESSION SET EVENTS '10015 TRACE NAME ADJUST_SCN LEVEL 1';

10. ALTER DATABASE OPEN

11. Trying selecting rows from a table

12. If the instance crashes again, check the trace file for another
ORA-00600 [2662] error. If so, go back to step 9 and increment the
LEVEL by 1 and repeat steps 9 through 12 until you can successfully
select rows. If you need to go beyond level 6 or 7, then the database
is probably too far gone to continue.


*************************************************************************
* *
* CAUTION: Once the database is open, it is imperative that you export, *
* rebuild the database, and import. *
* *
* By forcing open the database in this fashion, there is a strong *
* likelihood of logical corruption, possibly affecting the data *
* dictionary. Oracle does not guarantee that all of the data will be *
* accessible nor will it support a database that has been opened by *
* this method and users allowed to continue work. All this does is *
* provide a way to get at the contents of the database for extraction, *
* usually by export. It is up to you to determine the amount of lost *
* data and to correct any logical corruption issues. *
* *
*************************************************************************



Search Words:
=============

ORA-1194







------------OR

Doc ID: Note:30681.1
Subject: EVENT: ADJUST_SCN - Quick Reference
Type: REFERENCE
Status: PUBLISHED
Content Type: TEXT/PLAIN
Creation Date: 20-OCT-1997
Last Revision Date: 04-AUG-2000
Language: USAENG


ADJUST_SCN Event
~~~~~~~~~~~~~~~~
*** WARNING ***
This event should only ever be used under the guidance
of an experienced Oracle analyst.
If an SCN is ahead of the current database SCN, this indicates
some form of database corruption. The database should be rebuilt
after bumping the SCN.
****************

The ADJUST_SCN event is useful in some recovery situations where the
current SCN needs to be incremented by a large value to ensure it
is ahead of the highest SCN in the database. This is typically
required if either:
a. An ORA-600 [2662] error is signalled against database blocks
or
b. ORA-1555 errors keep occuring after forcing the database open
or ORA-604 / ORA-1555 errors occur during database open.
(Note: If startup reports ORA-704 & ORA-1555 errors together
then the ADJUST_SCN event cannot be used to bump the
SCN as the error is occuring during bootstrap.
Repeated startup/shutdown attempts may help if the SCN
mismatch is small)
or
c. If a database has been forced open used _ALLOW_RESETLOGS_CORRUPTION
(See )


The ADJUST_SCN event acts as described below.

**NOTE: You can check that the ADJUST_SCN event has fired as it
should write a message to the alert log in the form
"Debugging event used to advance scn to %s".
If this message is NOT present in the alert log the event
has probably not fired.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the database will NOT open:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Take a backup.
You can use event 10015 to trigger an ADJUST_SCN on database open:

startup mount;

alter session set events '10015 trace name adjust_scn level 1';

(NB: You can only use IMMEDIATE here on an OPEN database. If the
database is only mounted use the 10015 trigger to adjust SCN,
otherwise you get ORA 600 [2251], [65535], [4294967295] )

alter database open;

If you get an ORA 600:2256 shutdown, use a higher level and reopen.

Do *NOT* set this event in init.ora or the instance will crash as soon
as SMON or PMON try to do any clean up. Always use it with the
"alter session" command.

~~~~~~~~~~~~~~~~~~~~~~~~~~
If the database *IS* OPEN:
~~~~~~~~~~~~~~~~~~~~~~~~~~
You can increase the SCN thus:

alter session set events 'IMMEDIATE trace name ADJUST_SCN level 1';

LEVEL: Level 1 is usually sufficient - it raises the SCN to 1 billion
(1024*1024*1024)
Level 2 raises it to 2 billion etc...

If you try to raise the SCN to a level LESS THAN or EQUAL to its
current setting you will get - See below.
Ie: The event steps the SCN to known levels. You cannot use
the same level twice.

Calculating a Level from 600 errors:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get a LEVEL for ADJUST_SCN:

a) Determine the TARGET scn:
ora-600 [2662] See Use TARGET >= blocks SCN
ora-600 [2256] See Use TARGET >= Current SCN

b) Multiply the TARGET wrap number by 4. This will give you the level
to use in the adjust_scn to get the correct wrap number.
c) Next, add the following value to the level to get the desired base
value as well :

Add to Level Base
~~~~~~~~~~~~ ~~~~~~~~~~~~
0 0
1 1073741824
2 2147483648
3 3221225472