This is an excerpt from the bestselling book
Oracle Grid & Real Application Clusters. To get immediate
access to the code depot of working RAC scripts, buy it
directly from the publisher and save more than 30%.
One important mount option that is useful for
setting up the file systems for an Oracle database is DB Optimized.
PolyServe specially provides the DB Optimized option for the use of
database files. This option bypasses file system I/O buffering
allowing disk transfers to occur directly in application buffers.
This allows a database system, such as RAC, to manage its own data
coherency and integrity.
To take advantage of the performance
optimization, the read or write system call buffer must be aligned
on a page boundary and the I/O must be 512 bytes or a multiple
offset. The size of the I/O must also be 512 bytes or a multiple
thereof. Oracle I/O is sized as a db_block_size operation and will
always be a 512 byte multiple.
In such a case, the files in the DB Optimized
file system are treated as direct I/O files, and the I/O is
completely un-buffered and not serialized through any OS locking.
Any access to files in a DB Optimized mounted file system that do
not fit the alignment requirements do succeed ? through the buffered
I/O path. Regular file system commands can be used against these
files such as cp, rm, compress, etc.
DB Optimized file systems are used to store all
Oracle data files, redo logs, control files, SPFILE, OCR file, and
CRS voting disk.
Configure Veritas CFS for Solaris and HP
Another option available for Solaris and HP
platform is the use of Veritas Advance Cluster solution, which
provides comprehensive cluster software and shared storage
solutions. In this section, the shared storage solution will be
examined in terms of the Veritas cluster file system (CFS).
Setting up volumes and making sure the cluster
file system is accessible by all nodes configures the shared
storage. In sum the volumes and the CFS depend on the physical
storage. The cluster volume manager manages all related objects such
as physical disks (LUNS), disk groups, volumes, and file systems.
Oracle uses the ODM (Oracle disk manager) interface to communicate
with Veritas volumes and CFS files.
Cluster Volume Manager (CVM)
CVM is basically an extension of the widely
used Veritas Volume Manager. CVM extends the functionality of the
VxVM to all the nodes in the cluster. Each node sees the same state
of all volume resources. It follows master/slave architecture. One
node usually acts as master and others as slaves. There is only one
master in a given cluster. The volume manager daemon (vxconfigd)
maintains the configuration of the logical volumes. Each node in the
node has the vxconfigd daemon. Changes to a volume are propagated
first to the master daemon and then the master passes it on to slave
daemons. These changes happen at the kernel level.
CVM does not attempt to do any locking between
the nodes. That is the responsibility of the application, as in the
RAC database. CVM also follows the uniform shared storage model.
This means that all systems must be connected to the same disk sets
for a given disk group. If a node loses contact with a specific
disk, it is excluded from using the disk.
Cluster File System (CFS)
Veritas CFS has evolved from the Veritas File
System (VxFS). CFS allows the same file system to be simultaneously
mounted on multiple nodes in the cluster. Once again, the CFS is
designed with master/slave architecture. Though any node can
initiate an operation to create, delete, or resize data, the master
node carries out the actual operation. CFS caches the metadata in
memory, typically in the memory buffer cache or the vnode cache. A
distributed locking mechanism, called GLM, is used for metadata and
cache coherency among the multiple nodes. However, with
implementation of the ODM interface, Oracle RAC accesses data files
stored on CFS, bypassing the file system buffer and file system
locking processes. Oracle manages its own consistency mechanism. The
ODM facility is automatically invoked with RAC.