RMAN can seamlessly restore and recover backups from previous incarnations to the current incarnation. To perform point-in-time recovery to a target time prior to the most recent RESETLOGS, however, you must run the RESET DATABASE command to reset the database to the incarnation current at the desired target time.
Assume the following situation:
You run RMAN with a recovery catalog.
You made a backup of target database trgt on October 2, 2002.
You performed incomplete recovery on this database and opened it with the RESETLOGS option on October 10, 2002. A new database incarnation was created.
On October 25, you discover that you need crucial data that was dropped from the database at 8:00 a.m. on October 8, 2002. You decide to reset trgt to the prior incarnation, restore the October 2 backup, and recover to 7:55 a.m. on October 8.
Note:
It is not possible to restore one datafile of a previous incarnation while the current database is in a different incarnation--you must restore the whole database.
To recover the database by means of a backup from the old incarnation:
Obtain the primary key of the prior incarnation with a LIST command: # obtain primary key of old incarnation
LIST INCARNATION OF DATABASE trgt;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- ------- ------ ------- ---------- ----------
1 2 TRGT 1224038686 PARENT 1 02-OCT-02
1 582 TRGT 1224038686 CURRENT 59727 10-OCT-02
Make sure the database is started but not mounted: SHUTDOWN FORCE NOMOUNT
Reset the incarnation to the primary key that you just obtained: # reset database to old incarnation
RESET DATABASE TO INCARNATION 2;
Recover the database, performing the following actions in the RUN command:
Set the end time for recovery to the time just before the loss of the data.
If automatic channels are not configured, then manually allocate one or more channels.
Restore the control file and mount it.
Restore and recover the database.
For example, run the following commands:RUN
{
# set time to just before data was lost.
SET UNTIL TIME 'Oct 8 2002 07:55:00';
RESTORE CONTROLFILE; # FROM AUTOBACKUP not needed in catalog mode
ALTER DATABASE MOUNT; # mount database after restoring control file
RESTORE DATABASE;
RECOVER DATABASE;
}
If recovery is successful, then reset the online redo logs: # this command automatically resets the database so that this incarnation is
# the new incarnation
ALTER DATABASE OPEN RESETLOGS;
Thursday, September 24, 2009
Subscribe to:
Post Comments (Atom)
Blog Archive
-
▼
2009
(30)
-
▼
September
(15)
- Cloning Oracle Database - Cold Cloning, Hot Cloning
- Recovering a Lost Datafile Without a Backup: Example
- Recovering a Database in NOARCHIVELOG Mode: Example
- Restoring When Multiple Databases in the Catalog S...
- Restoring Datafile Copies to a New Host: Example
- Recovering Blocks Listed in V$DATABASE_BLOCK_CORRU...
- Performing Disaster Recovery
- Testing the Restore of a Database to a New Host: S...
- Determining the SCN for Incomplete Recovery After ...
- Point-in-Time Recovery to a Previous Incarnation
- Performing Point-in-Time Recovery with a Current C...
- Performing Database Point-In-Time Recovery
- To recover the database with a backup control file...
- To recover the database with an autobackup of the ...
- Oracle Database Block corruption
-
▼
September
(15)
About Me
- Palani Vijay
- Working as Oracle DBA for Wipro Technologies, Chennai, India
No comments:
Post a Comment