RMAN Point-In-Time Recovery

RMAN Point-In-Time Recovery Example

There are many ways to restore a database using an RMAN backup – this example assumes you are running RMAN without a Catalog and are performing a Restore & Point-In-Time Recovery of all data back to a particular date/time in the past.

If you are running in Archive log mode and recover without specifying a date/time then RMAN will apply all Archived logs it can find, ofter recovering the database right back to the time when you started the restore operation!

If you are running in Archive log mode (and you should be), point-in time is probably the most common recovery scenario.

You will need the following information:

Database SID: ________

Database SYS password: ________

The Date and Time to restore to : ________

There are 5 steps to recover the database:

1) Restore backup files from tape
2) Mount the instance
3) Restore the datafiles
4) Recover the database
5) Reset the logs

Restore backup files from tape

If you are looking to restore the database to a time of (say 09:00) you will need the most recent RMAN backup files prior to the date (say 23:00 from the previous day) plus all the archive logs from the backup time until the restore time, in this case from 23:00 until 09:00.

If any of these files have been moved (e.g. archived to tape) restore them to the default locations on the oracle database server.

Mount the instance

C:\> Set ORACLE_SID=Live

RMAN:> shutdown immediate;
RMAN:> startup mount;

Restore and recover the datafiles

RMAN> run
allocate channel dev1 type disk;
set until time “to_date(‘2010-30-12:00:00:00’, ‘yyyy-dd-mm:hh24:mi:ss’)”;
restore database;
recover database; }

For a large database it can take a long time to restore each tablespace – for better performance during a restore place the RMAN backup files on a separate disk to the Oracle datafiles to reduce disk contention.

Open the database and reset logs

RMAN> alter database open resetlogs;

This will update all current datafiles and online redo logs and all subsequent archived redo logs with a new RESETLOGS SCN and time stamp.

As soon as you have done a resetlogs run a full backup, this is important as should you suffer a second failure you will not be able to perform a second recovery because after resetting the logs the SCN numbers will no longer match any older backup files.

original article : http://ss64.com/ora/rman_pitr_example.html



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s