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

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. Always reserve free disk space for growing volumes and file systems. You can
also preallocate sufficient space for each file system when the file system is first created or
manually grow the file system and logical volume where the file system resides.
See the vxassist(1) and fsadm_vxfs(1) manual pages for more information.
Performance of Storage Checkpoints
Veritas File System attempts to optimize the read and write access performance on both the
Storage Checkpoint and the primary file system. Reads from a Storage Checkpoint typically
perform at nearly the throughput of reads from a normal VxFS file system, allowing backups to
proceed at the full speed of the VxFS file system.
Writes to the primary file system are typically affected by the Storage Checkpoints because the
initial write to a data block requires a read of the old data, a write of the data to the Storage
Checkpoint, and finally, the write of the new data to the primary file system. Having multiple
Storage Checkpoints on the same file system, however, will not make writes slower. Only the
initial write to a block suffers this penalty, allowing operations like writes to the intent log or
inode updates to proceed at normal speed after the initial write.
The performance impact of Storage Checkpoints on a database is less when the database files
are Direct I/O files. A performance degradation of less than 5 percent in throughput has been
observed in a typical OLTP workload when the Storage Checkpoints only keep track of changed
information. For Storage Checkpoints that are used for storage rollback, higher performance
degradation (approximately 10 to 20 percent) has been observed in an OLTP workload. The
degradation should be lower in most decision-support or data-warehousing environments.
Reads from the Storage Checkpoint are impacted if the primary file system is busy, because the
reads on the Storage Checkpoint are slowed by all of the disk I/O associated with the primary
file system. Therefore, performing database backup when the database is less active is
recommended.
Performance of Storage Checkpoints 33