10.3 Scalability | Oracle Real Application Clusters

< Day Day Up >

The RAC scalability feature is its basic architecture and is made possible by the various features offered through the technology. RAC is a clustered database solution, where one copy of a physical database could be accessed from two or more nodes or instances. Which means that an instance or node could join or leave the cluster dynamically (provided the database has been created to provide for this feature). What this means is that when a node or instance crashes, Oracle will reconfigure the membership to the cluster and continue functioning as a cluster with fewer instances. Similarly, when a node or instance joins the cluster, it reconfigures the membership to the cluster and continues functioning as if some additional resource was dynamically added to the instance.

Some of the scalability features we have already discussed in the previous chapters include:

New cache fusion technology: All data communication or sharing of global memory information happens via the high-speed cluster interconnect, providing sharing of data across instances and only writing to disk when it absolutely needs to.
Dynamic reconfiguration of resources: When a node or instance joins or leaves the cluster, Oracle is able to dynamically register this fact and balance the additional resources to the instance that joined the cluster or the resources from the instance to the available instances when an instance leaves the cluster.
Fast recovery feature: Due to the shared database architecture, any instance could recover the data that belonged to another instance by reading the redo logs of the instance.
Listener load balancing: Where multiple users try to make connections to an Oracle instance and the local listener is busy, Oracle will automatically load balance to the other instance provided the load balancing parameter has been set to ON (LOAD_BALANCE = ON) in the tnsnames.ora file.
Addition of nodes or instances dynamically: This provides for easy business growth. As the business grows and as more and more users access the available instance, making it highly resource intensive, additional instances could be added to the cluster dynamically, allowing distribution of workload to the new instances and thus providing scalability of the database servers. While more nodes or instances are added to the existing configuration, apart from the basic instance configuration no additional database-related activities or additional databases are required. These additional instances will share the already available common physical database.
Users from all nodes or instances access the common shared physical database to retrieve data simultaneously: This means that multiple users from multiple instances could access the same piece of information simultaneously, and all lock-related activity, when users' processes from the various instances request for the same data, is handled by the GCS across the cluster interconnect.

10.3.1 Configuring RAC for scalability

RAC can be configured as an active/passive configuration, where one node is only active at any given point of time, while the other node is inactive or in a passive state and is used only when the active instance fails. The main goal for this kind of configuration is availability and failover; when one node in the cluster fails, users are migrated to the other instance on another node. This feature is implemented using the Oracle RACG. The drawback to such a configuration is that one instance is idle all the time (until the primary instance fails) and capital investment is not being utilized.

This type of configuration could be achieved without a RAC configuration where one Oracle instance is installed on shared storage mounted on one node, and when the node fails, the other node could remount the disks. The failed-over node then becomes the active node (this depends on the O/S failover capabilities).

Note

When RAC is implemented using an active/passive state, the total node/instance count is always two and addition of further nodes is not possible.

The other type of configuration is where nodes have been configured to be in an active/active state. Which means all the instances are in a usable state and no instance is idle at a given point in time. This is where the true functionality of a RAC implementation is obtained. RAC, when configured to be in an active/active state, provides availability and scalability provided that certain parameters are configured during the database creation time.

CREATE DATBASE 'PRODDB' MAXINSTANCES 8 MAXLOGFILES 48 MAXDATA FILES 1024 MAXLOGHISTORY 1024 CHARACTER SET UTF8 NATIONAL CHARACTER SET 'UTF8'' CONTROLFILE REUSE

All the parameters used in the database creation command help in the scalability of the database; considerable care should be taken in calculating the appropriate values for these parameters. These values should be arrived at based on the future capacity requirements of the enterprise. This is possible through various interviews, capacity planning and on factors like the number of new users that the system will have. This will help determine the additional number of instances would be required.

For example, the MAXINSTANCES parameter used during database creation defines the number of instances that the database server would ever have. This does not necessarily mean that during the initial setup there would be eight instances (in the example listed above) sharing a common shared physical database. It just means potentially many instances could simultaneously have this database mounted and open. This value takes precedence over the value of initialization parameter INSTANCES.

Setting this parameter to a higher value allows Oracle to create the control file with appropriate space allocated for these instances when they are actually added to the cluster. Another advantage of setting the MAXINSTANCES parameter to a higher value would be to help the plug-and-play capability of the instances. That is, instances could be easily added to the cluster without any significant change to the database.

The downside of not allocating a high value to the MAXINSTNACES parameter is that the control file will have to be re-created when additional instances above the MAXINSTANCES parameter are added to the cluster.

Note

The value of the MAXINSTANCES parameter should not be an arbitrary value; it should be arrived at by using capacity planning techniques and based on business requirements.

Similarly, based on the value of the MAXINSTANCES parameter, the MAXLOGFILES and MAXLOGHISTORY parameters are sized because these parameters are all related to the number of instances.

MAXLOGFILES specifies the maximum number of redo log file groups that can ever be created for the database. During the control file creation, Oracle uses this value to allocate the names of these redo log files.
MAXLOGHISTORY is useful only when using Oracle in ARCHIVELOG mode with RAC. It specifies the maximum number of archived redo log files for automatic media recovery of RAC. During the creation of the control file, Oracle uses this value to allocate the names of archived redo log files. The default value is a multiple of MAXINSTANCES value and depends on the O/S.

One of the main advantages of sizing these parameters appropriately is that instances could be added to the cluster dynamically, while all other basic configuration requirements have been taken care of.

< Day Day Up >