VERITAS Storage Foundation 4.1 for Oracle RAC HP Serviceguard Storage Management Suite Extracts, December 2005

Determining Space Requirements for Storage Checkpoints
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.
Note For more information on mountable Storage Checkpoints, see “Mounting Storage
Checkpoints Using sfrac_ckptmount” on page 148.
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 allocated to store the original block content. Subsequent
changes to the same block require no overhead or block allocation.
If a file system that has Storage Checkpoints runs out of space, by default VxFS removes
the oldest Storage Checkpoint automatically instead of returning an ENOSPC error code
(UNIX errno 28- No space left on device), which can cause the Oracle instance
to fail. Removing Storage Checkpoints automatically ensures the expected I/O semantics,
but at the same time, eliminates a key recovery mechanism.
When restoring a file system that has data-full Storage Checkpoints from tape or other
offline media, you need extra free space on the file system. The extra space is needed to
accommodate the copy-on-write algorithm needed for preserving the consistent image of
the Storage Checkpoints. The amount of free space required depends on the size of the
restore and the number of Storage Checkpoints on the file system.
If you are restoring the entire file system, in most cases, you no longer need the existing
Storage Checkpoint. You can simply re-make the file system using the mkfs command,
and then restore the file system from tape or other offline media.
Chapter 7, Using Storage Checkpoints and Storage Rollback 131