Oracle Real Application Clusters

In this chapter we looked extensively at the transaction management principles of cache fusion. We looked at the various scenarios or behavioral patterns that are encountered in a normal day-to-day operation in an enterprise in a clustered database configuration. With extensive details including process flows, a step-by-step description of each behavior was given.

In a RAC configuration, as we have discussed, most of the activity is done within the SGA or across the cluster interconnect and a copy maintained within an instance. If one instance required a block that is currently held by another instance, we also looked at how the holding instance would transfer the block to the requesting instance, after making updates to the required GRD on the resource master node.

Under OPS, this was one of the biggest performance nightmares. The transfer of blocks was performed by writing an image or version of the block to disk to allow the requesting instance to read this off the disk. Transferring blocks of information across the interconnect is not cheap, either; when multiple instances are required to transfer large volumes of data, high latency issues could be encountered. This requires the database administrator to tune not only the database servers but also the network cluster interconnect to ensure lower latencies.

We also discussed the internals of transaction management and the steps that take place once a user executes a statement and the results are sent back. These operations are performed via the parse phase of a transaction's life cycle.

In the next chapter we will look at parallel operations, and parallel operations in a clustered database environment. How can database operations be executed in parallel across multiple instances and how does Oracle manage these parallel operations? We will also look into how Oracle decides if the operation should be executed on one node or on multiple nodes.