VERITAS Storage Foundation 4.1 Oracle Administrator's Guide

Chapter 8, Using Storage Checkpoints and Storage Rollback
Prerelease 8 September 2005, 8:55am Using Storage Checkpoints and Storage Rollback for Backup and Restore
163
Using Storage Checkpoints and Storage Rollback for Backup and
Restore
VERITAS Storage Foundation for Oracle provides a Storage Checkpoint facility that is similar to
the snapshot file system mechanism; however, a Storage Checkpoint persists after a system reboot.
A Storage Checkpoint creates an exact image of a database instantly and provides a consistent
image of the database from the point in time the Storage Checkpoint was created. The Storage
Checkpoint image is managed and available through the VxDBA utility, the GUI, or the VERITAS
Storage Foundation for Oracle command line interface (CLI). VERITAS NetBackup also makes
use of Storage Checkpoints to provide a very efficient Oracle backup mechanism.
Note For more information on creating Storage Checkpoints with the CLI, see “Managing Storage
Checkpoints” on page 348 and “VERITAS Storage Foundation for Oracle Command Line
Interface” on page 418.
A direct application of the Storage Checkpoint facility is Storage Rollback. Because each Storage
Checkpoint is a consistent, point-in-time image of a file system, Storage Rollback is the restore
facility for these on-disk backups. Storage Rollback rolls back blocks contained in a Storage
Checkpoint into the primary file system for restoring the database faster. For more information on
Storage Checkpoints and Storage Rollback, see the VERITAS File System Administrator’s Guide.
Understanding Storage Checkpoints and Storage Rollback
A Storage Checkpoint is a disk and I/O efficient snapshot technology for creating a “clone” of a
currently mounted file system (the primary file system). Like a snapshot file system, a Storage
Checkpoint appears as an exact image of the snapped file system at the time the Storage
Checkpoint was made. However, unlike a snapshot file system that uses separate disk space, all
Storage Checkpoints share the same free space pool where the primary file system resides unless a
Storage Checkpoint allocation policy is assigned. A Storage Checkpoint can be mounted as
read-only or read-write, allowing access to the files as if it were a regular file system. A Storage
Checkpoint is created using the dbed_ckptcreate command or the GUI.
Initially, a Storage Checkpoint contains no data—it contains only the inode list and the block map
of the primary fileset. This block map points to the actual data on the primary file system. Because
only the inode list and block map are needed and no data is copied, creating a Storage Checkpoint
takes only a few seconds and very little space.
A Storage Checkpoint initially satisfies read requests by finding the data on the primary file system,
using its block map copy, and returning the data to the requesting process. When a write operation
changes a data block n in the primary file system, the old data is first copied to the Storage
Checkpoint, and then the primary file system is updated with the new data. The Storage Checkpoint
maintains the exact view of the primary file system at the time the Storage Checkpoint was taken.
Subsequent writes to block n on the primary file system do not result in additional copies to the
Storage Checkpoint because the old data only needs to be saved once. As data blocks are changed