Architecture considerations and best practices for architecting an Oracle RAC solution with Serviceguard and SGeRAC

20
Oracle Disk Manager
One of the major key features provided with Serviceguard SMS CFS for RAC is the database
accelerator, ODM. ODM is a standard API specified by Oracle for database I/O. The VERITAS
implementation of ODM improves performance by providing the database direct access to the
underlying storage without passing through the actual file system interface. The resulting performance
is equivalent to performance when using raw devices. The performance improvements are based on
the following:
• File System Direct I/O
With this feature, Oracle disk I/O bypasses the HP-UX buffer cache to provide the following
benefits:
– Improved system efficiency—Oracle uses its own buffer, System Global Area (SGA), to cache
disk I/O. It has better knowledge than the HP-UX kernel about which Oracle data objects must be
buffered, so it is more efficient to devote memory to the SGA than to the HP-UX buffer cache for
Oracle databases.
– Improved I/O performance—without File System Direct I/O, each Oracle I/O would be buffered
twice, once in the SGA and then in the OS buffer cache. In addition to using the memory
inefficiently, this double buffering also consumes additional CPU resources (an additional
memory-to-memory system call is required). Using File System Direct I/O avoids double buffering
and its negative impact on I/O performance.
• Asynchronous File System I/O (/dev/async)
Normally, direct I/O is synchronous, which can significantly downgrade write performance. For
example, an application would block a write I/O until the write completed. With Asynchronous File
System I/O, the direct I/O is asynchronous in the same way as when the database is deployed on
raw volumes.
For Oracle RAC on CFS,
19
Storage Checkpoints
the ODM feature provides near-raw volume performance with the
manageability of a file system.
Another key feature of Serviceguard SMS CFS for RAC is Storage Checkpoints. Storage Checkpoints
enable efficient backup and recovery of an Oracle database. The Storage Checkpoint facility is
similar to the snapshot file system mechanism except that a Storage Checkpoint persists after a system
restart. A Storage Checkpoint creates an exact image of a database instantly and provides a
consistent image of the database from the time the Storage Checkpoint is created. Like a snapshot file
system, a Storage Checkpoint appears as an exact image of the snapshot file system at the time the
Storage Checkpoint is 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. A Storage
Checkpoint can be mounted as read-only or read-write, allowing access to files as if it were a regular
file system. VERITAS NetBackup also makes use of Storage Checkpoints to provide a very efficient
Oracle backup mechanism.
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 faster database recovery. Storage rollback restores a database, a
tablespace or datafiles in the primary file system 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.
19
The use of ODM is required when storing Oracle RAC database data on a CFS file system.