In addition to the normal performance metrics monitored in a single-instance environment, an Oracle RAC environment requires that some additional metrics be monitored. Primarily, we recommend that the MAA DBA focus on metrics related to messages across the interconnect, to gauge the amount of traffic across the interconnect and also the response time. This traffic essentially falls into two categories when it comes to your Oracle RAC database: Global Cache Services (GCS) and Global Enqueue Services (GES).
Global cache service
GCS relates to the concept of the global buffer cache, which is integral to the Cache Fusion concepts. As such, global cache is referring to database blocks. The GCS is responsible for maintaining cache coherency in this global buffer cache by ensuring that any time an instance attempts to modify a database block, a global lock resource is acquired, avoiding the possibility that another instance modifies the same block at the same time. The instance making the change will have the current version of the block (with both committed and uncommitted transactions) as well as a past image of the block. Should another instance request that block, it is the duty of the GCS to track who has the block, what version of the block they have, and what mode the block is held in. The LMS process is the key component of the GCS.
Global enqueue service
In addition to the maintenance and management of database blocks themselves, it is also incumbent in an Oracle RAC environment that certain other resources be coordinated between nodes. The GES is responsible primarily for maintaining coherency in the dictionary cache and the library cache.
The dictionary cache is essentially a cache of data dictionary information stored in the SGA of an instance for fast access. Since this dictionary information is stored in memory, changes on one node that result in dictionary changes (such as Data Definition Language [DDL] statements) must be immediately propagated to the dictionary cache on all nodes. The GES is responsible for handling this, and avoiding any discrepancies between instances.
By the same token, library cache locks are taken out on objects within the database for parsing of SQL statements that affect those objects. These locks must be maintained among instances, and the GES must ensure that deadlocks do not occur between multiple instances requesting access to the same objects. The LMON, LCK, and LMD processes work together to perform the functions of the GES.
GV$ views
With all of this globalization discussed so far, it is only natural that we point out the addition of global views in an Oracle RAC environment. Global views are the same as the more commonly used V$ views, except that they will have a column added called INST_ID, which will map to the instance_number of each instance in the cluster. As such, in a three-node cluster, queries against a GV$ view will give you three times as many rows, because each instance will have its own set of data to display. Knowing this, you can query stats for a specific instance or all instances without needing to connect specifically to each node.
An example of some of the information you can gather is shown in the following query:
This allows you to see, with one query, that instance number 1 has sent 716 gcs messages, whereas instance number 2 has sent 57325 messages, a disparity that may warrant further investigation.
Very Impressive and neatly written note .. Thanks so much ..