As I was searching the net for interesting items, I saw a blog entry by Umair. So I have included his blog entry here with a few minor changes. To reach his blog site…
On this entry the discussion was about the main difference when monitoring a Oracle Rac Database as compared to a single instance Oracle database. What I particularly liked was how clear the explanation was. So I have taken key points from his blog entry and put them here.
The main difference to keep in mind when monitoring a RAC database versus a single-instance database is the buffer cache and its operation. In a RAC environment the buffer cache is global across all Oracle instances in the cluster and hence how it handles the processing of the buffer cache differs.
First Checks to see if Data is in Local Data Cache
When a process in a RAC database needs to modify or read data, Oracle will first check to see if it already exists in the local “data” buffer cache of the instance you are on. If the data is not in the local buffer cache then global buffer cache will then be inspected to see if the data it needs is already located in another Oracle instance “data” buffer cache.
Second checks other Oracle Instances Caches
If the data it needs is located in another Oracle instance already, the remote instance will send the data to the local instance via the high-speed interconnect, thus avoiding a disk read. This is a much faster way to provide you the data, then getting it via a disk read.
Monitoring a RAC database often means monitoring this situation and the amount of requests going back and forth over the RAC interconnect. The most common wait events related to this are
gc cr request
gc buffer busy
gc cr request
This “gc cr request” wait event, also known as global cache cr request prior to Oracle 10g, specifies the time it takes to retrieve the data from the remote cache.
High wait times for this wait event often are because of:
RAC Traffic Using Slow Connection – typically RAC traffic should use a high-speed interconnect to transfer data between instances, however, sometimes Oracle may not pick the correct connection and instead route traffic over the slower public network. This will significantly increase the amount of wait time for the gc rc request event. The oradebug command can be used to verify which network is being used for RAC traffic:
SQL> oradebug setmypid
SQL> oradebug ipc
This command sequence will dump a trace file to the location specified by the user_dump_dest Oracle “Init.Ora” parameter containing information about the network and protocols being used in the RAC interconnect.
Inefficient Queries, poorly tuned queries will increase the amount of data blocks requested by an Oracle session. The more blocks requested typically means the more often a block will need to be read from a remote instance via the interconnect.
gc buffer busy
This “gc buffer busy” wait event, also known as global cache buffer busy prior to Oracle 10g, specifies the time the remote instance locally spends accessing the requested data block. This wait event is very similar to the buffer busy waits wait event in a single-instance database and are often the result of:
Hot Blocks – multiple sessions may be requesting a block that is either not in buffer cache or is in an incompatible mode.
Deleting some of the hot rows and re-inserting them back into the table may alleviate the problem. Most of the time the rows will be placed into a different block and reduce contention on the block. The DBA may also need to adjust the pctfree and/or pctused parameters for the table to ensure the rows are placed into a different block.
Remember pctfree determine how much space oracle reserves in a data block for future updates.
Inefficient Queries as with the gc cr request wait event, the more blocks requested from the buffer cache the more likelihood of a session having to wait for other sessions. Tuning queries to access fewer blocks will often result in less contention for the same block.
To see Umair’s original blog entry unchanged….
Posted by Michael Corey