< Day Day Up >

---

Chapter 5: Transaction Management

5.1 Introduction

In the previous chapter we discussed the architecture of RAC, introducing the various components that distinguish the RAC architecture from a regular single instance Oracle configuration. While RAC acts as an extension to the regular single instance configuration, there are quite a few differences in the management of the components, the additional background process required, the additional files, and the sharing of resources between instances. It is in the RAC configuration that the real difference between a database and an instance is noticed as they are uniquely identified. While this difference does exist in a regular single instance configuration, this is seldom noticed because they are not distinguished from each other like in a RAC configuration. During the process of discussing the various architectural components pertaining to the RAC implementation, we also looked into some common new features like the AUM, GCS, GRD, etc.

Among the many great advantages of using a RAC configuration is availability. In a clustered configuration continuous availability is obtained by load balancing users across multiple instances. When one instance fails, the user process is transferred to one of the other available instances in the cluster. We also discussed the failover and recovery processes. The previous chapter formed an introduction to the architectural features of RAC; we will revisit these features in their respective chapters.

In this chapter we will discuss one such area, namely transaction management, describing how data is shared between instances, and how user requests are processed when they are requested simultaneously from multiple instances. How does the clustered database solution support concurrent transaction management? When users access the same information from multiple instances how is the data shared, how is data integrity maintained, and how is data coherency maintained across these instances and across these requests?