Veritas Storage Foundation™ 5.0.1 for Oracle RAC Installation, Configuration, and Administrator's Guide Extracts for the HP Serviceguard Storage Management Suite on HP-UX 11i v3

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 on the primary file system, the Storage Checkpoint gradually fills with the original
data copied from the primary file system, and less and less of the block map in the Storage
Checkpoint points back to blocks on the primary file system.
You can set a quota to limit how much space a file system will give to all storage checkpoints,
to prevent the checkpoints from consuming all free space. See the command dbed_ckptquota
for more information.
Storage Rollback restores a database, a tablespace, or datafiles on the primary file systems to the
point-in-time image created during a Storage Checkpoint. Storage Rollback is accomplished by
copying the “before” images from the appropriate Storage Checkpoint back to the primary file
system. As with Storage Checkpoints, Storage Rollback restores at the block level, rather than at
the file level. Storage Rollback is executed using the dbed_ckptrollback command.
NOTE: Whenever you change the structure of the database (for example, by adding or deleting
datafiles, converting PFILE to SPFILE, or converting SPFILE to PFILE), you must run
dbed_update.
Mountable Storage Checkpoints can be used for a wide range of application solutions, including
backup, investigations into data integrity, staging upgrades or database modifications, and data
replication solutions.
If you mount a Storage Checkpoint as read-write, the command does not allow you to roll back
to this Storage Checkpoint. This ensures that any Storage Checkpoint data that has been modified
incorrectly cannot be a source of any database corruption. When a Storage Checkpoint is mounted
as read-write, the dbed_ckptmount command creates a “shadow” Storage Checkpoint of and
mounts this “shadow” Storage Checkpoint as read-write. This allows the database to still be
rolled back to the original Storage Checkpoint.
For more information on mountable Storage Checkpoints see the Veritas Storage Foundation for
Oracle Administrator's Guide available on the SG SMS media and at: http://www.docs.hp.com
Determining Space Requirements for Storage Checkpoints
To support Block-level Incremental (BLI) Backup and storage rollback, the file systems need
extra disk space to store the Storage Checkpoints. The extra space needed depends on how the
Storage Checkpoints are used. Storage Checkpoints that are used to keep track of the block
changes contain only file system block maps, and therefore require very little additional space
(less than 1 percent of the file system size).
If the database is online while the backup is running, the additional space required by each file
system for Storage Checkpoints depends on the duration of the backup and the database workload.
If workload is light during the backup or the backup window is relatively short (for example,
for incremental backups), for most database configurations, an additional 10 percent of the file
system size will be sufficient. If the database has a busy workload while a full backup is running,
the file systems may require more space.
To support Storage Checkpoints and storage rollback, VxFS needs to keep track of the original
block contents when the Storage Checkpoints were created. The additional space needed is
proportional to the number of blocks that have been changed since a Storage Checkpoint was
taken. The number of blocks changed may not be identical to the number of changes. For example,
if a data block has been changed many times, only the first change requires a new block to be
32 Using Storage Checkpoints and Storage Rollback