Fun With Oracle - RMAN Tutorial - Recovery Methods
Fun With Oracle - RMAN Tutorial - Recovery Methods
Disclaimer: This document is not a replacement for any ORACLE document or whitepaper. This is merely
meant for understanding certain fundamental aspects of RMAN recovery process.
$ sqlplus “/ as SYSDBA”
SQL> shutdown abort;
ORACLE instance shut down.
Next, you need to start up your target database in mount mode. RMAN cannot restore
datafiles unless the database is at least in mount mode, because RMAN needs to be able
to access the control file to determine which backup sets are necessary to recover the
database. If the control file isn't available, you have to recover it first. Issue the STARTUP
MOUNT command shown in the following example to mount the database:
Since backup set files are created in an RMAN-specific format, you must use RMAN to
restore the datafiles. To use RMAN, connect to the target database:
$ rman target /
The remainder of this example shows how to restore all of the datafiles of the target
database.
Note : When the restore command is executed, RMAN will automatically go to its
last good backup set and restore the datafiles to the state they were in when that
backup set was created.
When restoring datafiles, RMAN reads the datafile header and makes the determination
as to whether the file needs to be restored. The recovery is done by allocating a channel
for I/O and then issuing the RMAN restore database command.
With Oracle9i and above, you don't need to allocate a channel explicitly. Instead, you can
use the default channel mode:
RMAN> restore database;
RMAN> recover database;
SQL> alter database open;
For Oracle8i, the ALLOCATE, RESTORE, and RECOVER commands need to be
enclosed by the run{} command:
RMAN> run {
allocate channel d1 type disk;
restore database;
recover database;
}
alter database open;
Note :Once the recovery has been completed, execute a complete RMAN backup to
establish a new baseline.
Restoring Specific tablespaces
In this scenario, it is assumed that your control files are still accessible. You have a
backup, done for example with backup database plus archivelog;
Take the tablespace that needs recovery offline, restore the tablespace, recover the
tablespace, and bring the tablespace online. If you cannot take the tablespace offline,
then shutdown abort the database and restore in mount mode.
First try to take the tablespace offline.
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/11/2010 11:03:23
RMAN-06054: media recovery requesting unknown log: thread 1 seq 1 lowscn 8448414
Since the online logs were lost, complete recovery is not possible. Open the database with
resetlogs to continue.
RMAN> alter database open resetlogs;
-------------------------------------IMPORTANT-------------------------------------------
During this type of recovery, if you receive error messages like this:
With the database mounted, execute ‘alter database backup controlfile to trace resetlogs;’
Perform a shutdown abort on the database, but remain at the SQL> prompt.
In another telnet session, go to the udump directory to retrieve the resulting trace file and
copy it to another location to edit it.
Edit the file and add the phrase “until cancel” to the recover database command at the end. The
phrase should read “recover database until cancel using backup controlfile”. Remove the
“alter database open” command after the recover command. Save the file with a .sql extension.
Back at the SQL> prompt, execute the modified trace file. When prompted for an archived log,
type in “cancel” and the reply should be “media recovery cancelled”.
Issue “alter database open resetlogs”. The database should open after a few moments.
Connect to the RMAN recovery catalog and issue the “reset database” command.
----------------------------------------------------------------------------------------
Time-Based, Change-Based / SCN-based Incomplete Recovery
Incomplete recovery uses a backup to produce a non-current version of the database. In other
words, youdo not apply all of the redo records generated after the most recent backup.
You usually perform incomplete recovery of the whole database in the following situations:
A user error causes data loss, for example, a user inadvertently drops a table.
You cannot perform complete recovery because an archived redo log is missing.
You lose your current control file and must use a backup control file to open the database.
To perform incomplete media recovery, you must restore all datafiles from backups created prior to
the time to which you want to recover and then open the database with the RESETLOGS option
when recovery completes. The RESETLOGS operation creates a new incarnation of the database;
in other words, a database with a new stream of log sequence numbers starting with log sequence
1.
NOTE – Start every RMAN incomplete recovery with the following commands:
$ sqlplus "/ as sysdba"
SQL> shutdown abort;
SQL> startup mount;
$ rman target /
Delete prior backups with this command (from the RMAN prompt):
RMAN> delete force backup;
Note :This command removes all prior backups from the RMAN catalog as they
can no longer be used once the database has been restarted with the resetlogs
option. After completing this command, create a new RMAN backup to establish a
new baseline.
$ rman target /
RMAN> restore ARCHIVELOG FROM TIME 'SYSDATE-1' UNTIL TIME 'SYSDATE';
or
RMAN> restore ARCHIVELOG FROM TIME "to_date('07/11/10 00:00:01','MM/DD/YY HH24:MI:SS')
UNTIL TIME 'SYSDATE';