Databases Reference
In-Depth Information
restore database;
recover database;
}
RMAN> alter database open resetlogs;
If everything went well, you should now see output similar to this:
Statement processed
How It Works
SCN-based incomplete database recovery works in situations where you know the SCN value up to where you want
to end the restore and recovery session. RMAN will recover up to, but not including, the specified SCN. RMAN
automatically terminates the restore process when it reaches the specified SCN.
To view the current SCN of your database, query the V$DATABASE view:
SQL> select current_scn from v$database;
You can view historical SCN information for your database in several ways:
•
As detailed in Recipe 12-5, you can use LogMiner to determine an SCN associated with a DDL
or DML statement.
•
You can look in the alert.log file.
•
You can look in your trace files.
•
You can query the FIRST_CHANGE# column of V$LOG, V$LOG_HISTORY, and
V$ARCHIVED_LOG.
If you have set the initialization parameter
log_checkpoints_to_alert
to TRUE, then every time a log switch
occurs, Oracle will write the SCN of each checkpoint to your target database alert.log file. This feature can be handy
when trying to determine historical checkpoint SCN activity. Here's an excerpt from the alert.log file that shows the
SCN of a checkpoint for a database that has
log_checkpoints_to_alert
set to TRUE:
Beginning log switch checkpoint up to RBA [0x15.2.10], SCN: 1063491
You can also view SCN information by querying data dictionary views. For example, you can query
V$ARCHIVED_LOG to display the first SCN and time that it was generated, as shown here:
SELECT
sequence#
,first_change#
,first_time
FROM v$archived_log
ORDER BY first_time;
Once you determine the SCN to which you want to recover, you can use the
until scn
clause of the
restore
and
recover
commands to perform incomplete database recovery.
