Review of Clustered Features + Architecture
Oracle 9iRAC has some important hardware and software components which are distinct from a standard single-instance setup.
On the hardware side, you have the IPC interconnect. On high-end specialized hardware such as sun clusters, you have a proprietary interconnect. On our low-cost working-mans clustering solution, you simply use a private or public ethernet network. The Oracle software components which we’ll describe in detail below, use this interconnect for interprocess communication, sending messages to syncronize caches, locks, and datablocks between each of the instances. This sharing of cache information is called Cache Fusion, and creates what Oracle calls the Global Cache.
Another important piece of the 9iRAC pie is the storage subsystem, and the Oracle cluster filesystem. What we’ve created with our cheap firewire shared drive is affectively a SAN or Storage Area Network. In high-end systems this SAN would probably be built with fiber-channel technology and switches. This storage subsystem is sometimes called a shared-disk subsystem. In order to write to the same disk being accessed by two machines, you have your choice of raw devices, or OCFS. Raw devices can also be used with a single instance database. They eliminate completely the OS filesystem, and all associated caching and management, providing direct raw access to the device. This type of arrangement is more difficult to manage. You don’t have datafiles to work with, so your backups, and database management become a bit more complex. Also, adding new datafiles is always adding a new partition, thus they are more difficult to delete, resize, and rearrange. OCFS provides you this functionionality, but with the flexibility and simplicity of a filesystem. Definitely the recommended option.
Oracle’s cluster manager (the oracm process we started above) coordinates activities between the cluster of instances. It monitors resources, and makes sure all the instances are in sync. If one becomes unavailable, it handles that eventuality.
With a 9iRAC database, aside from the normal SMON, PMON, LGWR, CKPT, + DBWR processes, you have a number of new processes which show up. They are as follows:
PROCESS NAME DESCRIPTION
——- —————– ———————-
LMSn global cache services controls the flow of data blocks + messages
LMON global enqueue monitor monitors global locks
LMD global enqueue service daemon: manages remote resource requests
LCK lock process manages local library and row cache req
DIAG diagnosability daemon reports process failures to alert.log
In 9iRAC there are two important components which manage shared resources. They are Global Cache Services (GCS) (Block Server Process or BSP in 8iOPS) and Global Enqueue Services (GES) components. GCS shares physical blocks from the buffer caches of each instance in the cluster, passing them back and forth as necessary. The GES shares locking information. In the local context you have three types of resource locks – null, shared, and exclusive. A null lock generally escalates to other types of locks, and strange as it may seem, doesn’t convey any access rights. Multiple instances can gain a null lock. Multiple instances can acquire a shared lock for reading, however, while it is in shared mode, other instances cannot write to it. And an exclusive lock can be held by only one instance. It gives exclusive access for writing. In the global context, ie whenever Cache Fusion is invoked, or whenever two instances in a cluster want the same data, you have those same three locks in two modes. Ownership of the current image or past image. The issue of the past image comes up because in a single instance, another session can construct the past image from undo, however, in the global context, this has to be put together and passed along to the other instance in the cluster.
The physical database in and Oracle 9iRAC environment has a lot in common with a single instance database. In 9iRAC, each instance has it’s own ORACLE_HOME where the Oracle software, ORACLE_BASE/admin/ORACLE_SID directory in OFA where the bdump, udump, cdump, pfile, and create directories all are. Each instance also has it’s own archive logs, if you are running in archivelog mode. The example above I was not running in archivelog mode, for simplicity sake. All the other files which make up your database are shared, including datafiles for data, datafiles for index, redo, system, temp, and other tablespaces, as well as controlfiles.