Oracle Real Application Clusters

15.1 Introduction

In the previous chapter, the discussion was centered around tuning a single instance configuration of the Oracle database. We stated that a methodology should be created/defined and followed during performance testing of the application and the database. We discussed how the application could be divided into quadrants and performance testing each quadrant through an iterative cycle. There are two ways of approaching the performance tuning of the application. One way is a top-down approach where the application tier is performance tuned first, then the instance, and subsequently the database. Another way is a bottom-up approach where the storage system is tuned first, followed by the database, instance, and application. While the second approach has less impact on the application, using the top-down approach is more robust.

We discussed the tuning aspects of the application tier, followed by the Oracle instance, and then looked at the areas to tune in a database tier by discussing the various I/O-related wait events. There were also discussions regarding areas of the system that are influenced by certain waits and what remedies could be applied to reduce their impact.

Clustered instance and database tuning should commence only after the single instance tuning has completed. There is an old quote, ''A stitch in time saves nine.'' If you do not complete the single instance tuning before tuning the cluster, it will be a terrible mistake, and if this approach is taken, you will need to include additional days/weeks in the implementa tion project plan in case it needs to start all over again.

A clustered database configuration comprises a single instance database configuration first, and then further instances are added to help provide scalability of the application. The important components in the clustered database configuration are the interconnect that communicates between instances and the storage that is shared from multiple instances.

Normally, in a complete application development life cycle, it would be best practice to start tuning the application first. However, when migrating from a single instance configuration to a clustered configuration, or when the single instance configuration has been tuned to a great extent, to reduce the impact on the overall applications it would be a better practice to start tuning bottom up. As mentioned, the two important components in a RAC configuration are the cluster interconnect and the shared storage subsystem. Our goal here is to start with the storage subsystem and then move into the cluster interconnect, and then into the instance and database tuning.