Veritas Storage Foundation 5.0 for Oracle RAC Configuration Guide Extracts for HP Serviceguard Storage Management Suite, Second Edition, May 2008

Using Storage Checkpoints and Storage Rollback
Determining Space Requirements for Storage Checkpoints
Chapter 4
45
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.
If you are restoring some of the files in the file system, you should first remove the
data-full Storage Checkpoints that are no longer needed. If you have very limited free
space on the file system, you may have to remove all data-full Storage Checkpoints in
order for the restore to succeed.
To avoid unnecessary Storage Checkpoint removal, instead of using a low quota limit use
the SFDB utility to set up a Monitoring Agent to monitor file system space usage. When
file system space usage exceeds a preset threshold value (say, 95 percent full), the
Monitoring Agent alerts the system administrator and optionally grows the volume and
the file system. Automatic notifications to the system administrator on the status of
space usage and file system resizing are available through electronic mail, the
syslogd(1M) program, or by logging messages to a simple log file.