Solution Description:
=====================

First, look to see if you can find the correct redo logs. They are absolutely
necessary for media recovery. Without them, we cannot apply undo and changes
to bring the database to a point in time consistent state.

If the online redo logs have been deleted, restore from backup and roll
forward with the archive logs.

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.


*******WARNING**********************************************************

The following parameters are to be used with caution, as they do exploit
the database. In addition, the use of these parameters is not supported
and may not work in all circumstances. You should only be using these
parameters with the help of a senior analyst.

The consequences of using these parameters is that they will corrupt the
database and you will be required to rebuild your database.

************************************************************************


After reading and understanding the consequences of the above warnings, do the
following to force the database open:

1. Shutdown the database and take a full backup of the current database

2. Add the following parameters in the init.ora:

_allow_resetlogs_corruption=TRUE
_corrupted_rollback_segments= <list of all your rollback segments>

3. Comment out the rollback_segments parameter

4. Startup mount the database

5. Do:

SVRMGR> recover database using backup controlfile until cancel:

6. When prompted, type in the word 'bogus' or some other nonsense file
name. Recovery will attempt to find a file with this name and fail.
It may provide an error message and prompt you for another file, or
it may simply fail and terminate the recovery session. Either is OK.

7. If prompted for another logfile, type CANCEL.

8. Do:

SVRMGR> alter database open resetlogs;

** Note: This step may fail. If so, we will need to investigate
the errors produced in more detail. If this succeeds,
proceed to step 9.

9. REBUILD the database by taking a full database export, and then
importing into a new database.


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.


Regards!