Tuning Global Cache - Expert Oracle RAC Performance Diagnostics and Tuning - page 379

Chapter 13
Tuning Global Cache
Real Application Cluster (RAC) can be considered as an extension to the single instance configuration. As a concept,
this is true, because RAC is a composition of several instances of Oracle. However, there are quite a few differences
in the management of these components, the additional background process, the additional files, and the sharing
of resources between instances, not to mention the additional layered components present at the operating system
level to support a clustered hardware environment. All of these additional components in a RAC system make it
different from a single-instance configuration. It is also in a RAC configuration that the real difference between a
database and an instance is noticed. Although this difference does exist in a regular single-instance configuration, this
is seldom noticed because the database and an instance are not distinguished from each other as they are in a RAC
configuration (e.g., in a single-instance configuration, the instance and the database are identified by the same name).
When multiple instances access the same database, data retrieved by the user sessions on the various instances
are maintained in the local instance. Subsequently, if another user in another instance requires the same data, the
data is transferred over the interconnect to the requesting instance through “Cache Fusion,” that is, provided the data
has not been modified or the data has not been flushed out of the local cache buffer: when data is pushed out of the
buffer cache due to cache replacement and the data is re-read from disk, or if cached in another RAC instance, read
via the private interconnect. When data is transferred from one instance to the other, the sending instance sends
copies of the blocks to the requesting instance. Depending on whether the request is for write or read and on internal
policies of Cache Fusion, the sending instance changes the status of the locally cached data and may retain a current
or past version of the data in its buffer cache before sending. This means multiple instances can potentially have
the same blocks of data, or versions of the same data at different times (i.e., current as of a certain SCN) Whereas
regular instance management rules apply to data copies within the instance, data access and data sharing across
instances needs to be managed from a global level across the cluster within the boundaries of server pools and across
one or more instances through the use of database services. Modifications to data need to be globally consistent
and guarantee coherence. The global cache and Cache Fusion implements a state machine via message passing to
guarantee global cache coherence. Cache Fusion does not use locks in the traditional sense; it maintains and passes
state via messages.
Global Cache
When reading or modifying data across instances, it's all about locating the data blocks, making a request to the object
master, and allowing the data to be transferred from the holding instance to the requesting instance. These services
are performed by two processes: global cache service (GCS) and global enqueue services (GES).
When a user session requires a data block to satisfy its operation, the GCS uses the global resource directory
(GRD) to look up the whether the data is located in the cache of another instance or on disk and requests the desired
read or write access to the block. The GCS processes are using the GRD to maintain the status of each object and each
cached block on the respective instances. Contents of the GRD are distributed across all the active instances, and its
entries require a small amount of memory per buffer, which effectively increases the memory requirements for the