4.14 Conclusion

---

In this chapter the architecture of RAC was explored by detailing the various features of the cache fusion technology, how cache fusion operates, how blocks are shared across the instances, and how they are managed in such a way that only one instance makes changes to the block at any moment. Also discussed was the provision to cache memory between the various instances by GCS, how resources are mastered on an instance with a new concept of a resource directory, and how the GCS and GES communicate with the GRD. The additional background and foreground processes available only in a RAC implementation were also investigated.

One of the greatest advantages of a clustered database solution is continual provision of availability of data to the users. It was discussed in brief how failover operation works in a RAC environment and how recovery operation happens during an instance failure. Although Oracle has been configured to recover from failures very quickly, failures can severely disrupt users by dropping connections to the database. Work in progress at the time of the failure is most likely lost. If the user queried, for example 1000 rows from the database, and a failure on the node occurred while the user was scrolling through these rows on his/her browser, the failure would cause the user to re-execute the query and browse through these rows again. This disruption could be eliminated for most situations by masking the failure with the transparent application failover (TAF) option. Features such as TAF and a more detailed discussion about availability and scalability features of RAC are forthcoming in Chapter 10.

How the various files used in a RAC implementation are managed as part of the architecture was also discussed. Certain files such as the data files and control files are shared and others, such as the redo log files and the archived log files, are required to be maintained specifically for an instance. How the parameter file that was previously maintained, specific to an instance, could be configured as shared by using the appropriate qualification (e.g., RAC3.UNDO_TABLESPACE) was explored.

Finally, comparing the traditional method of the rollback segment approach versus the new undo management approach completed architectural discussions about the new features of undo management.

More discussions around the undo management are also forthcoming in a subsequent chapter when the availability and recovery operation in a RAC implementation is discussed.

In the next chapter, the transaction management life cycle in a RAC implementation will be explored along with the use of various test scenarios, beginning with the time a user places a request for information to the point that the data/information is returned back to the user. Transaction management, with respect to queries and DML operations, will also be covered.

---