Backing Up and Recovering the Database Using Storage Checkpoints

Storage Checkpoints can be created by specifying one of the following options: online, offline, or instant. To create a Storage Checkpoint with the online option, the database should be online and you must enable ARCHIVELOG mode for the database. For the offline option, the database should be offline.

During the creation of the Storage Checkpoint, the tablespaces are placed in backup mode. Because it only takes a few seconds to take a Storage Checkpoint, the extra redo logs generated while the tablespaces are in online-backup mode are very small. You can roll back the entire database or individual tablespaces or datafiles to an online or offline Storage Checkpoint. After the rollback is complete, you may roll the database forward to restore the database if you have used an online Storage Checkpoint.

For the instant option, the database should be online and it can be running in either ARCHIVELOG or NOARCHIVELOG mode. You can only roll back the entire database to an instant Storage Checkpoint. Rolling back individual tablespaces or datafiles to an instant Storage Checkpoint is not possible. After the rollback is complete, you need to perform database recovery. Rolling the database forward is not supported; that is, you cannot apply archived redo logs.

To allow the easiest recovery, always keep ARCHIVELOG mode enabled, regardless of whether the database is online or offline when you create Storage Checkpoints.

Verifying a Storage Checkpoint Using the Command Line

After creating a Storage Checkpoint and before using it to back up or restore a database, you can verify that the Storage Checkpoint is free of errors using the procedure below.

Usage Notes

• See the dbed_ckptcreate(1M) and dbed_ckptmount(1M) manual pages for more information.

  To verify that a Storage Checkpoint is error-free using the command line

1. Create and mount a Storage Checkpoint:
   $ /opt/VRTS/bin/dbed_ckptcreate -S PROD -H /oracle/product -o online
      Creating online Storage Checkpoint of database PROD.
      Storage Checkpoint Checkpoint_903937870 created.
   
      $ mkdir /tmp/ckpt_ro
   
   $ /opt/VRTS/bin/dbed_ckptmount -S PROD \
   -c Checkpoint_903937870 -m /tmp/ckpt_ro

   ---

     Note    If the specified mount point directory does not exist, then dbed_ckptmount creates it before mounting the Storage Checkpoint, as long as the Oracle DBA user has permission to create it.

   ---

2. Examine the content of the Storage Checkpoint:
      $ ls -l /tmp/ckpt_ro/dbvol_82/dbinst1
      drwxr-xr-x       3  oracle     dba   1024       Nov 11 2000 . 
      drwxr-xr-x       3  oracle  dba   512       Nov 16 11:00 .. 
      -rw-r--r--       1  oracle     dba   209747968        Nov 16 10:58 .tstmp
      -rw-r--r--       1  oracle dba   209747968       Nov 16 10:58 .tstab
      lrwxrwxrwx       1  oracle  dba   18       Nov 11 2000 tstmp -> \
                             .tstmp::cdev:vxfs:
      lrwxrwxrwx       1  oracle   dba   18       Nov 11 2000 tstab -> \
                             .tstab::cdev:vxfs:
3. Run dbv tool against Quick I/O file tstmp:
   DBVERIFY: Release 9.2.0.2.0 - Production on Mon Mar 7 11:48:35
   2005

Storage Checkpoints can only be used to restore from logical errors (for example, a human error). Because all the data blocks are on the same physical device, Storage Checkpoints cannot be used to restore files due to a media failure. A media failure requires a database restore from a tape backup or a copy of the database files kept on a separate medium. The combination of data redundancy (disk mirroring) and Storage Checkpoints is recommended for highly critical data to protect them from both physical media failure and logical errors.