4
Local Resource Coordination

This chapter provides an overview of resource coordination and a description of local resources that are employed by the Global Cache Service (GCS) and Global Enqueue Service (GES).

Topics in this chapter include:

• Overview of Resource Coordination

• Resource Coordination Components

• Local Concurrency Controls

  See Also: Chapter 5, "Cache Fusion and the Global Cache Service" for information on the GCS, and Chapter 6, "Coordination by the Global Enqueue Service" for information on the Global Enqueue Service

Overview of Resource Coordination

There are three general categories of concurrency control used by the Real Application Clusters software:

• Independent resources

• Global Cache Service resources

• Global Enqueue Service enqueues

This chapter primarily discusses Independent resources.

Oracle uses these concurrency controls to maintain buffer cache coherency and perform other synchronization tasks. This guarantees database integrity in a clustered environment. To transfer data blocks among database caches, buffers are transferred by way of a high speed interconnect. Just as in a single instance system, disk writes are required for cache replacement.

Real Application Clusters synchronizes global resources among all active instances in a cluster. There are two main types of global resources:

• Resources used by the Global Cache Service for resource management.

• Global resources that Oracle synchronizes within a cluster to coordinate GES enqueues

Oracle uses the Global Cache Service (GCS), Global Enqueue Service (GES), and independent resources to maintain buffer cache coherency and perform other synchronization tasks. Together, they guarantee database integrity in a clustered environment.

Coordination of concurrent tasks within a shared cache server is called synchronization. Resources such as data blocks and enqueues must be synchronized as nodes within a cluster acquire and release their ownership. The synchronization provided by Real Application Clusters maintains cluster-wide concurrency of the resources and in turn ensures the integrity of the shared data.

The key to successful cluster database processing is to divide the tasks that require resources among the nodes so that very little synchronization is necessary. The less synchronization that is necessary, the better your system's speed up and scale up. The overhead of synchronization can be very expensive if excessive internode communication is necessary.

Synchronization among nodes is accomplished with the high-speed IPC interconnect linking the clustered processors. For cluster database processing within a node, messaging is not necessary; shared memory is used instead. Messaging and enqueuing among nodes is handled by the GES.

The amount of synchronization depends on the amount of resources and the number of users and tasks working on the resources. Little synchronization might be needed to coordinate a small number of concurrent tasks, but many concurrent tasks can require significant synchronization.

Real Application Clusters employs a Global Resource Directory distributed across all instances in a cluster. Resources are mastered at one instance. The GCS and GES manage the resources that they master.

See Also: Chapter 2, "Real Application Clusters Architecture" for information on resource mastering and resource affinity. See Chapter 10, "High Availability Concepts and Best Practices" for information on resource remastering in node failover

Resource Coordination Components

The components within a cluster database that require concurrency control include:

• Row level access

• Block level access

• Space Management

• System Change Number (SCN) creation

• Data dictionary cache

• Library cache

Local Concurrency Controls

There are three types of local concurrency controls: latches, enqueues, and row locks. Latches do not affect the global operations of clustered environments. Enqueues, however, can be both local to an instance and global to a cluster. While locking is automated in Real Application Clusters, it does employ independent row locks.

Latches

A latch is a simple, low level serialization mechanism that protects a critical resource. All latches are local. Latches do not protect datafiles, they are automatic, and they are held for a very short duration. Latches are either in use or free. Each critical resource has its own latch. As mentioned, because latches are synchronized within a node, they do not facilitate internode synchronization.

Local Enqueues

A local enqueue is a shared memory structure that serializes access to database resources. Enqueues are local to one instance when Real Application Clusters is not enabled. However, when Real Application Clusters is enabled, enqueues can be global to a database. Enqueues are associated with a session or transaction. Oracle can use enqueues in any of three modes:

• null (N) mode

• shared (S) mode

• exclusive (X) mode

Enqueues are held longer than latches, have finer granularity, have more modes than latches, and protect more database resources. For example, if you request table lock, or a Database Mount Lock, your request is assigned an enqueue.

See Also: Oracle9i Database Reference for descriptions of all GES enqueues

Row Locks

Row locks are locks that protect selected rows. The following statements create row locks:

• INSERT

• UPDATE

• DELETE

• SELECT with the FOR UPDATE clause

These locks are stored in the block, and each lock refers to the global transaction lock.

As in single instance Oracle, Real Application Clusters controls concurrency down to the row level. (The finest lock granularity is at the row level.) This is a key advantage of Real Application Clusters over competing parallel processing systems. To keep the cache coherent, access to the data blocks is controlled by the GCS.

GCS resources and row locks operate independently of the GCS. An instance can disown a GCS resource without affecting row locks held in the set of blocks managed by the GCS. A row lock is acquired during a transaction. During a transaction, the GCS can transfer blocks between instances, independently of when transactions commit.

In contrast, transactions do not release row locks until changes to the rows are either committed or rolled back. Oracle uses internal mechanisms for concurrency control. These isolate transactions so modifications to data made by one transaction are not visible to other transactions until the transaction modifying the data commits. The row lock concurrency control mechanism is independent of the GCS. Concurrency control does not require GCS resources, and GCS resource operations do not depend on individual transactions committing or rolling back.