11.7 Migrating from a single instance to RAC | Oracle Real Application Clusters

< Day Day Up >

Beginning with Oracle Version 9i Release 2, most of the hardware platforms, except a few, support the clustered file system for a RAC implementation. Others such as Sun Solaris and HP-UX do not support a clustered file system solution for RAC. If the hardware platform of choice is one of these platforms, it is required that RAC is implemented on raw devices (unless third party solutions, such as VERITAS CFS is used).

To migrate a single instance database to RAC, the following procedures are to be completed:

Configuration of the hardware platform: Based on the hardware platform selected, the appropriate cluster configuration directions should be followed from the vendor-specific documentation. Validate all tests to ensure that the hardware installed and configured is performing as per the specifications defined by the appropriate vendors.
Creation of raw devices or configuration of the clustered file systems: This depends on the clustered hardware platform selected and is based on Oracle's support for a clustered file system or a raw device. More details of raw device or clustered file system configuration are provided in Chapter 8 (Installation and Configuration). As discussed in Chapter 8, it is important that sufficient planning of the sizes of the various partitions be done prior to raw partitioning of these devices.
Evaluation of partitioning strategy if not already present: If the current database system does not have a data-partitioning strategy, consider the possibilities of partitioning the data based on a certain business attribute or function. For example, in a cable or satellite broadcasting system it could be the smart card or the set-top box number; in a customer management system it could be customer ID; in a logistics system, it could be the paying company ID. All these attributes could help group transactions records together, forming data partitions. If the current database has a partitioned schema, this schema could be implemented in a RAC environment.
Evaluation of the optimizer mode in the current application: If the current (legacy) application is configured to work with the rule-based optimizer, while migrating to Oracle 9i, it would be advantageous to move towards the cost-based optimizer. However, this migration is a crucial step, as all queries will have to be individually validated on a system with a cost-based optimizer and tuned for performance.
Evaluation of tablespaces and log files of single instance: Based on the raw device partition size analysis performed in step 1, determine the appropriate tablespaces that could be mapped to these partitions.
Export of data from old database: Export the current production data. The method of exporting data could depend on the platform, including the operating system and architecture on which the new database will be implemented. For example, if the new hardware platform is on a similar operating system, then a dd command on Unix or an ocopy command on Windows would help perform the trick, as raw devices are used.

However, if during this migration process, the database configura tion is changed from a 32-bit version to a 64-bit version, it would be more appropriate to export the data from the 32-bit database and import it into the new database.

Similarly, if there were a character set conversion, for example from ASCII to UTF-8, in this case also the export method would be preferable over the dd or ocopy commands.

Install operating-system-dependent cluster software: Somewhere along these steps it is important to install and configure the clus tered software. The Unix technical operations group based on the hardware vendor configuration manuals performs this step. For the RAC implementation this is a very important step. Normally, for a stand-alone implementation of Oracle, this step is not performed and hence special system administrator skills is required when installing and configuring the cluster software. After successful installation of this software the following checks should be performed to ensure that the clusterware is properly functioning:

Throughput testing of the cluster interconnect.
Throughput testing between the database cluster and the application servers.
Heartbeat configuration testing including tracing of heartbeat activities.
Heartbeat timeout configuration testing, including tracing and validating occurrence of timeout at the specified intervals.
Crash recovery testing to ensure that the recovery of one node does not affect the other nodes in the cluster.
Crash recovery performance testing to ensure that the timings are as specified by the manufacturer.

All the above and other basic tests as stipulated by the manufacturer would ensure that all hardware validations have been completed as per vendor specifications. It is important to perform these steps at this stage to avoid any unknowns that may occur when additional hardware or software is added.

Note

For Unix, the information for the installation and configuration of the cluster software should be found in the vendor-provided documentation. For installation and configuration of the cluster software for the Windows or Linux operating systems, Oracle provides all the required preinstall tools.

Install Oracle 9i Enterprise Edition with the RAC and partitioning (optional) option: Installation of the Oracle Enterprise Edition is dependent on the clustered operating system being installed. The complete steps for installation and configuration of the Oracle RDBMS software have been detailed in Chapter 8 (Installation and Configuration).

Note

Certain features like the RAC option will not be visible from the Oracle installer unless the clustered operating system has been installed and configured correctly. The clustered operating system and its components should be visible to the OUI to provide visibility to the RAC option.

Create a new database: The next step after installation and configuration of the Oracle software is to install the database. For creation of the database, there are two options, either use the Oracle-provided DBCA utility or use the manual option for creating and configuring the Oracle database. Both these options have also been documented in Chapter 8 (Installation and Configuration).
Import data from old database to the new database: If the database structure including the physical layout, physical configuration, or the operating system has changed, it would be ideal to export the data from the current environment and import the data into this new environment.
Adjust the parameter values: When the database is initially created, the parameters all have default values, especially if the DBCA utility was used. Once the database has been created and all the required steps to bring the system online have been completed, then the next step is to configure all the parameters to match the parameter values in the current active instance.
Start the database: The next step after the initial configuration of the parameters is to start the instances on their respective nodes. The following commands could be used to start the database instance. Since this is a clustered database, there are multiple instances accessing the common physical database and each instance is required to mount and open the database for shared access.
Tune the instances: Tuning the instances starts very similarly to tuning a single instance configuration. Tune one instance first and apply the same changes to the other instances. When an instance has been tuned, the next step is to tune both instances in a clustered environment.

Note

There are no straightforward rules for tuning the instances or the clustered database. Tuning Oracle instances has come a long way from when it was considered to be an art and most of the tuning was achieved through trial and error. Today, Oracle provides a considerable amount of statistics that has changed the methodology to a scientific approach.

Tuning is also an iterative process, which means identifying problems, fixing them, then identifying new problems; once these are fixed, another set of problems are identified, and so forth.

A detailed analysis of the tuning of the instances, of the various areas of the clustered database, and of the clustered operating system will be discussed in Chapters 13, 14, and 15 on performance tuning.

< Day Day Up >