Local Resource :-It can be acted without consult to other instances. Local resource is a resource that is accessible to only one instance within the cluster.
Global Resource :- this will consult to another instance.(both instances). It can be an area in memory.A resource can be owned or locked in various states (exclusive or shared). Global resource is a resource that is visible to all the nodes within the cluster. Data buffer cache blocks are mostly used global resources. This transactions in cluster needs a directory maintain all information. That Directory is called Global resource directory.
GRD – Global Resource Directory
It is a part of the shared pool, whenever a block is transferred out of local cache to another instance’s cache grd is updated. It holds the meta data about data blocks, that are available in DBBC
It holds information like
1. SCN(System Change Number)
2. DBI(Data Block Identifier)
3. Location of the block
4. Mode of the block
Null (N) – Indicates that there are no access rides on block.
Shared(S) -Indicates that the block is share across the all instance
Exclusive(E) – Access rides only for particular instance
5. Role of the block
Local-Date block image present in only one node
Global-Data block image present in multiple nodes
6. Types of data block image
Current image-Update data block value
Consistent image-Previous data block value
Past image-GRD updated image
It convert to current image when instance is crash
GRD is depend on GES,GCS services
Global Cache Service Operations (GCS )
The GCS tracks the locations, modes, and roles of data blocks. The GCS therefore also manages the access privileges of various instances in relation to resources. Oracle uses the GCS for cache coherency when the current version of a data block is in one instance’s buffer cache and another instance requests that block for modification.
If an instance reads a block in exclusive mode, then in subsequent operations multiple transactions within the instance can share access to a set of data blocks without using the GCS. This is only true, however, if the block is not transferred out of the local cache. If the block is transferred out of the local cache, then the GCS updates the Global Resource Directory that the resource has a global role; whether the resource’s mode converts from exclusive to another mode depends on how other instances use the resource.
Global Cache Service Processing Example
Assume that an instance in a cluster database needs to update a data block. At the same time, another instance needs to update the same block. Without the cache coherency provided by the GCS, both instances could simultaneously update the same block. However, due to the synchronization controls of the GCS, only one instance can update the block; the other instance must wait.
By ensuring that only one instance can update a block at any time, the GCS maintains cache coherency. The blocks do not have to be held by an instance in exclusive mode until the instance’s transaction completes. For example, one instance can modify a row in a block while a transaction from another instance modifying a different row in the same block has not committed its changes.
Cache Coherency and the Global Cache Service
The GCS ensures cache coherency by requiring instances to acquire a resource at a cluster-wide level before modifying a database block. Thus, the GCS synchronizes global cache access, allowing only one instance at a time to modify a block.
Oracle’s multi-versioning architecture distinguishes between current data blocks and one or more consistent read (CR) versions of a block. The current block contains changes for all committed and yet-to-be-committed transactions.
A consistent read (CR) version of a block represents a consistent snapshot of the data at a point in time. The LMSn processes produce consistent read versions by applying rollback segment information to past images. Both current and consistent read blocks are managed by the GCS.
If one instance holds a block that it has modified and another instance requests it, then the holding instance maintains a past image (PI) of the block. In the event of failure, Oracle can reconstruct current and consistent read versions of the block by reading PIs.
Global Enqueue Service Operations (GES)
The Oracle uses GES en queues to manage concurrency for resources that operate on transactions, tables, and other entities within an Oracle Real Application Clusters environment. The following resources are local in single-instance Oracle databases, but they are global when they are under the control of the GES:
Each Real Application Clusters database instance has a dictionary cache, or row cache, containing data dictionary information. The data dictionary structure is the same for Oracle instances in a cluster database as it is for instances in single instance Oracle. However, in Real Application Clusters, Oracle synchronizes all the dictionary caches throughout the cluster. Real Application Clusters uses latches to do this, just as in single-instance Oracle databases.
Consider a five-node Real Application Clusters environment in which a user drops a table on one node. Because each dictionary cache, of which there are five, may have a copy of the definition of the dropped table, the node dropping the table from its cache must inform the other four dictionary caches to drop their copies of the definition. Real Application Clusters handles this automatically with messages managed by the GES.
When a database object, such as a table, view, procedure, package, or index, is referenced during the parsing of a SQL, DML, DDL, PL/SQL, or Java statement, the process that parses the statement acquires a library cache lock. In Oracle9i, the lock is held only until the parse or compilation completes, or, for the duration of the parse call.
RAC Background Processes
LMSx – The Global Cache Service Processes (LMSx) are the processes that handle remote Global Cache Service (GCS) messages. Real Application Clusters software provides for up to 10 Global Cache Service Processes. The number of LMSx varies depending on the amount of messaging traffic among nodes in the cluster.
The LMSx handles the acquisition interrupt and blocking interrupt requests from the remote instances for Global Cache Service resources. For cross-instance consistent read requests, the LMSx will create a consistent read version of the block and send it to the requesting instance. The LMSx also controls the flow of messages to remote instances.
The LMSn processes handle the blocking interrupts from the remote instance for the Global Cache Service resources by:
- Managing the resource requests and cross-instance call operations for the shared resources.
- Building a list of invalid lock elements and validating the lock elements during recovery.
- Handling the global lock deadlock detection and Monitoring for the lock conversion timeouts
LCKx – This process manages the global en queue requests and the cross-instance broadcast. Workload is automatically shared and balanced when there are multiple Global Cache Service Processes (LMSx).
DIAG: Diagnosability Daemon – Monitors the health of the instance and captures the data for instance process failures.
LMON: This process manages the GES, It maintains consistency of GCS memory structure in case of process death.It is also responsible for cluster reconfiguration and locks reconfiguration (node joining or leaving). It checks for instance deaths and listens for local messaging.
LMD: LMD0 processes enqueue resources managed under GES. In particular, LMD0 processes incoming enqueue request messages and controls access to global enqueues. It also performs distributed deadlock detection’s.
Every Instance have the own redo log files
It should be in shared
Why because of Instance recovery
Each instance can write to its own redo thread
->Archives redo logs -> Shared in local instance even.
-> For recovery we needs to keep in shared storage
Every instance having its own Undo Table space.
Every Node having its own instance.
Sp file of local instance is pointing to Sp file=+DG in shared storage.