Capacity Planning and Architecture - Expert Oracle RAC Performance Diagnostics and Tuning - page 39

At a later time when the user workload has stabilized (recovery is completed, users have failed over, etc.), GCS
and GES will reassess the situation and perform a re-mastering operation to place the master on the instance where
the demand is high.
A similar operation happens when an instance joins the cluster. Basically, a resource is removed from each of the
available instances and moved to the instance that joined the cluster.
Re-mastering also happens when a master is located on an instance that is not active. Oracle requires additional
resources to manage another resource master. Under these circumstances, Oracle will move the resource master that
is not being accessed to a less active instance.
For dynamic re-mastering to happen, the number of sessions touching an object should be 1,500 times more
than the other instances over a period of 10 minutes. 2
Lock Management
In the case of an Oracle implementation, a single stand-alone configuration, or a multi-instance configuration (RAC),
there is a considerable amount of sharing of resources between sessions. These resources could be a table definition,
a transaction, or any type of structure that is shareable between sessions. To ensure that the right sessions get access
to these resources based on their need and the type of activity being performed, they would require some type of lock
to be placed on them.
For example, a session trying to perform a SQL query, SELECT * FROM PRODUCT will require a shared lock on the
PRODUCT table. When a number of sessions try to access the same resource, Oracle will serialize the processing by
placing a number of these sessions in a wait mode until the work of the blocking sessions has completed.
Every session requiring access to these resources acquires a lock; and when it has completed the function or
operation, it releases the lock. Releasing of locks is performed by the sessions when the user issues a commit or
executes a data definition language (DDL) statement or by the SMON process if the session was killed.
Throughout its operation, Oracle automatically acquires different types of locks at different levels of
restrictiveness depending on the resource being locked and the operation being performed.
A RAC implementation is a composition of two or more instances that talk to a common shared database. Hence,
all transactional behaviors that apply to a single-instance configuration will apply to a RAC implementation.
Apart from the lock management of data manipulation language (DML), DDL latches and internal locks apply
to a single-instance configuration; the lock management in a multi-instance configuration involves management
of locks across instances and across the cluster interconnects. Sharing of resources does not happen within a
single instance; however, it happens across multiple instances. Another major difference between single-instance
configuration and a multi-instance configuration is that although row level locks continue to be maintained and
managed at the instance level, when it comes to inter-instance locking, the locking is at a much higher level, and the
locks are held at the block level. A block contains multiple rows or records of data.
A row does not have a master. A row is contained in a buffer whose state is globally known by the GCS and
the master. Object affinity and distributed resource manager only kicks in when a lock opens for a table, index, or
a partition. This happens when there is lot of disk I/O and no cache fusion. When data pings via the interconnect,
affinity and dynamic resource mastering (DRM) activity will not be initiated. In this case, not all blocks are transferred
over the interconnect; however, it is read from disk by performing a local disk I/O. In a RAC environment, when users
execute queries from different instances, instead of the server process having to retrieve data from the I/O subsystem
every single time, data is transferred (traditionally) over the interconnect from one instance to another. This provides
considerable performance benefits. 3 Once data is transferred to the requesting instance, the execution plan will then
traverse through these rows to extract the actual result set requested by the user.
2 These values are controlled by underscore parameters _GC_POLICY_MINIMUM and _GC_POLICY_TIME .
3 This is because the latency of retrieving data from an I/O subsystem is much higher compared to transferring data over the network.
Basically, network latency is much lower compared to I/O latency.