Database Reference
In-Depth Information
Multi-Instance Transaction Behavior
An instance reads a block from disk when either a user session or a process from another instance places a request.
Although all instances participating in the cluster could access the block directly from disk (as in the previous versions
of Oracle), 4 such an access would be expensive, especially when another instance in the cluster is already holding
a copy of the block in its buffer and the same block could be accessed via the cluster interconnect. This operation
maybe as simple as transferring the block via the cluster interconnect to the requesting instance. However, there are
other factors involved during this process; for example, the block held by the original holder may have been modified,
and the copy may not be placed on disk. It could very well be that the instance is holding only a copy of the block,
whereas the block was initially modified by another instance and the block may have already undergone considerable
changes. Yet, in another scenario, one of the instances requesting the block could be intending to delete a row from
the block, while yet another instance is intending to make updates to the block.
How are these changes by multiple instances coordinated? How does Oracle ensure that these blocks are
modified and tracked?
DBAs familiar with a single-instance configuration would know that Oracle is required to provide read
consistency and ensure that multiple sessions do not see the in-flight transactions or rows that are being modified
but not saved. RAC is no different; read consistency is provided at the cluster level across all instances. In a RAC
configuration, while the data movement is at the block level, a single row from the block behaves similar to a regular
single-instance configuration.
To cover all possible scenarios of cache fusion and sharing of blocks among the instances, the block behavior
could be broadly classified into the following:
Read/read behavior
Read/write behavior
Write/write behavior
Although these are just the high-level behaviors, there are quite a few possibilities that we discuss.
Read/Read Behavior
Under this behavior, there are basically two possibilities:
The instance that first requested the block is the only instance holding the block for read
purposes (read/read behavior with no transfer).
The first instance is holding the block for read purposes; however, other instances also require
access to the same block for read only purposes (read/read behavior with transfer).
Read/read Behavior with No Transfer
Figure 2-7 illustrates the steps involved when an instance acquires the block from disk and no other instance currently
holds a copy of the same block. Instance SSKY3 will have to request a shared resource on the block for read-only
purposes. ( For this discussion, we assume that SSKY3 is the first instance that requested this block, and it is not present in
the shared areas of any other instances [ SSKY1 , SSKY2 , and SSKY4 ]).
4 By enabling the gc_files_to_lock parameter, Oracle will disable the cache fusion functionality and instead would use the disks for
the sharing of blocks. In other words, it would use the Oracle parallel server (OPS) behavior.
 
Search WWH ::




Custom Search