< Previous  | TOC | Index | Next  >

Recovering a database using a Storage Checkpoint

Because Storage Checkpoints record the before images of blocks that have changed, you can use them to do a file-system-based storage rollback to the exact time when the Storage Checkpoint was taken. You can consider Storage Checkpoints as backups that are online, and you can use them to roll back an entire database, a tablespace, or a single database file. Rolling back to or restoring from any Storage Checkpoint is generally very fast because only the changed data blocks need to be restored.

  Note   Some database changes made after a Storage Checkpoint was taken may make it impossible to perform an incomplete recovery of the databases after Storage Rollback of an online or offline Storage Checkpoint using the current control files. For example, you cannot perform incomplete recovery of the database to the point right before the control files have recorded the addition or removal of datafiles. To provide recovery options, a backup copy of the control file for the database is saved under the /etc/vx/vxdbed/$ORACLE_SID/checkpoint_dir/CKPT_NAME directory immediately after a Storage Checkpoint is created. You can use this file to assist with database recovery, if necessary. If possible, both ASCII and binary versions of the control file will be left under the /etc/vx/vxdbed/$ORACLE_SID/checkpoint_dir/CKPT_NAME directory. The binary version will be compressed to conserve space. Use extreme caution when recovering your database using alternate control files.

Suppose a user deletes a table by mistake right after 4:00 p.m., and you want to recover the database to a state just before the mistake. You created a Storage Checkpoint (Checkpoint_903937870) while the database was running at 11:00 a.m., and you have ARCHIVELOG mode enabled.

If the Oracle RAC database is running under VCS control, you must perform the following steps before you recover the database:

1. As superuser, temporarily freeze the VCS resource group for the database.

   # hagrp -freeze resource_group

2. Shut down the primary database.
3. Run the dbed_ckptrollback command.
4. Unfreeze the resource group:

   # hagrp -unfreeze resource_group

 To recover the database using a Storage Checkpoint

1. Ensure that the affected datafiles, tablespaces, or database are offline, and use Storage Rollback to roll back any datafiles in the database that contained the table data from the Storage Checkpoint you created at 11:00 a.m.
2. Start up the database instance if it is down.
3. Re-apply archive logs to the point before the table was deleted to recover the database to 4:00 p.m. Use one of the following:

   recover database until cancel

   recover database until change

   recover database until time

4. Open the database with the following command:

   alter database open resetlogs

5. Delete the Storage Checkpoint you created at 11:00 a.m. and any other Storage Checkpoints created before that time.
6. Create a new Storage Checkpoint.