Chapter 11: Migrating to RAC

---

11.1 Introduction

In the previous chapter, we looked at the high-availability and scalability features of a clustered database solution such as RAC. RAC provides other normal features such as recoverability, manageability, and maintainability found in a stand-alone configuration of Oracle. However, availability and scalability are naturally derived from the architecture of the database configuration.

Hardware and operating system clustering provides failover opportu nities when a member in the cluster fails, thus providing continuous availability of the application to the users. Apart from the clustered failover options available at the operating system level, Oracle provides additional failover options through the TAF implementation. TAF pro vides transparent failover of the users' sessions from the failed instance to one of the other available instances. Much of the working of TAF, its configuration, implementation, and some performance aspects, was also discussed in the previous chapter.

With the introduction of Oracle 9i and the enhancement to the clustered database solution from the earlier version of OPS, considerable improvements have been made regarding the cache fusion technology, allowing users to access data from any instance participating in the clustered configuration and Oracle to transfer the information across the cluster interconnect. This feature of cache fusion replaces the expensive pinging activity that occurred in the earlier versions of Oracle.

OPS implementations required that the applications were specifically designed to use the clustering technology. This is because when an instance requested records that were already being worked against on another specific instance, the blocks that contained these rows had to be written to disk before the requesting instance could read it. This activity of writing to disk to provide visibility to the other requesting instance is called pinging and is a very expensive operation. The tuning of these pinging activities is a highly complex process; architects had to specifically design applications or have the existing applications redesigned to reduce sharing of data across instances.

In Version 9i, Oracle completed its implementation of the cache fusion technology, where data is transferred via the interconnect to the requesting instance, compared to writing the data to disk to make it available to the other instance, which provided limitations to scalability. RAC makes this version of the cluster database solution usable by most applications.

In this chapter we will discuss the migration of a single instance Oracle database to Oracle 9i RAC. During this process we will look into details such as, if RAC is required, will migration be feasible and what kind of complexities if any could be encountered during this migration process.

We will also discuss upgrading from a previous version of the clustered database OPS to Oracle 9i RAC. While the migration path from OPS to RAC should be much easier compared to the migration from a single instance, there are certain areas during the migration process where precautionary measures should be taken depending on the type of environment/application that the current database has been supporting. The first step is the analysis or the requirements process.

---