Oracle RAC Wait Events

RAC Differences

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 instances in the cluster and
hence the processing differs. 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
buffer cache. If the data is not in the local buffer cache the global buffer cache
will be reviewed to see if another instance already has it in their buffer cache. In
this case the remote instance will send the data to the local instance via the highspeed interconnect, thus avoiding 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 and gc buffer busy.
gc cr request
This 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:
1. RAC Traffic Using Slow Connection - typically RAC traffic should use a highspeed
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 will dump a trace file to the location specified by the user_dump_dest Oracle
parameter containing information about the network and protocols being used for
the RAC interconnect.
2. 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 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:
1. 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.
2. 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.
Conclusion
Oracle RAC is somewhat of a unique case of an Oracle environment, but
everything learned about wait events in the single instance database also applies
to clustered databases. However, the special use of a global buffer cache in RAC
makes it imperative to monitor inter-instance communication via the clusterspecific
wait events such as the ones discussed above. Understanding these
wait events will help in the diagnosis of problems and pinpointing solutions in a
RAC database.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/35489/viewspace-84626/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/35489/viewspace-84626/