4
Scalability in Real Application Clusters

This chapter provides detail about the scalability features of Real Application Clusters and includes the following topics:

• Scalability Features of Real Application Clusters
• All System Types Benefit from Real Application Clusters
• Levels of Scalability

Scalability Features of Real Application Clusters

You can implement Real Application Clusters using several features that enhance application performance and maintain high availability levels. These features:

• Balance workloads among the nodes by controlling multiple server connections during periods of heavy use
• Provide persistent, fault tolerant connections between clients and your Real Application Clusters database

If you install Real Application Clusters with one of the preconfigured databases, then the Database Configuration Assistant (DBCA) automatically configures most of these features.

See Also: Oracle9i Net Services Administrator's Guide for information about manually configuring scalability features

All System Types Benefit from Real Application Clusters

This section describes why all system types benefit from Real Application Clusters. It includes the following topics:

• Transaction Systems and Real Application Clusters
• Data Warehouse Systems and Real Application Clusters

  Note: If your application was well designed and ran efficiently on a single-instance Oracle database, then it will scale well on Real Application Clusters.

Transaction Systems and Real Application Clusters

Transaction systems are characterized by relatively brief database update transactions. Applications for transaction systems, which include e-business and traditional online transaction processing (OLTP) systems, perform well on Real Application Clusters. This is because Real Application Clusters provides excellent scale up. Cache Fusion enables updates to occur from multiple instances without overhead.

Because transaction systems manage more transactions as additional users connect to the system, you can increase capacity by dynamically adding nodes to the cluster. However, poorly designed systems do not scale well on either single-instance Oracle databases or on Real Application Clusters databases--poorly designed applications will likely experience performance degradation as demand increases.

Data Warehouse Systems and Real Application Clusters

Data warehouse systems perform well on Real Application Clusters because applications with low update activity can access the database through different instances without additional overhead. If the data blocks are not modified, then multiple instances can read the same blocks into their buffer caches and perform queries on the blocks without additional I/O. Data warehouse systems usually benefit from scale up and may experience speed up as well.

Oracle Parallel Execution in Real Application Clusters

Real Application Clusters provides the framework for parallel execution. Parallel execution performs efficiently in Real Application Clusters because it can distribute portions of a large SQL statement across multiple instances. The transaction is completed more quickly because it executes on multiple CPUs.

In Real Application Clusters, Oracle determines at runtime whether it will run parallel execution server processes on only one instance, or whether it will run processes on multiple instances. In general, Oracle tries to use only one instance when sufficient resources are available. This reduces cross-instance message traffic.

Levels of Scalability

Implementing cluster databases requires optimal scalability on the following levels as described in this section:

• Network Scalability
• Network Scalability and Client/Server Connectivity
• Operating System Scalability

  Note: Inappropriately designed applications might not fully use the potential scalability of a system. Likewise, regardless of how well your applications scale, you will not obtain optimal performance if you attempt to deploy your applications on hardware that does not scale.

Network Scalability

Interconnects are a key factor in cluster scalability. That is, every system must have a connection to the CPUs, whether the connection is a high-speed bus or a low-speed Ethernet connection. Bandwidth and latency of the interconnect then determine the scalability of the hardware.

Network Scalability as a Function of Bandwidth and Latency

Hardware scalability requires very low latency and most interconnects have sufficient bandwidth to accommodate Real Application Clusters internode processing. Other internode operations, such as parallel execution, also rely on high bandwidth.

Network Scalability and Client/Server Connectivity

In Real Application Clusters, client/server connections are established using several subcomponents. A client submits a connection request to a listener process residing on the target node. The listener grants a connection to a client so the client can access a particular node based on several factors. How the listener grants the connection depends on how you configure the connection options as described under the following headings:

• Connection Load Balancing Feature
• Enhanced Network Scalability and the Shared Server Feature

Connection Load Balancing Feature

The connection load balancing feature provides exceptional benefits in Real Application Clusters environments where there are multiple instances and dispatchers. Connection load balancing improves performance by balancing the number of connections among various instances and shared server dispatchers for the same service. Note that if your application is partitioned, you may not want to use this feature.

Because of service registration's ability to cross-register with remote listeners, a listener is always aware of all instances. Thus a listener can send an incoming client request for a specific service to the least-loaded instance and least-loaded dispatcher. Service registration also facilitates connect-time failover and client load balancing that you can use with or without a shared server. In addition, Oracle dynamically updates the initialization parameters that control connection load balancing when you add or remove nodes from your Real Application Clusters database.

Connect-Time Failover for Multiple Listeners

Service registration informs listeners whether an instance is running or stopped. This enables connect-time failover when multiple listeners support a service. To use this feature, configure a client to fail over client requests to a different listener if the initial listener connection fails. The reconnection attempts continue until the client successfully connects to a listener. If an instance fails, then a listener returns a network error.

Client Load Balancing and Connection Load Balancing for Multiple Listeners

Oracle Net provides client load balancing and connection load balancing. When more than one listener supports a service, a client can randomly send connection requests to the various listeners. The random nature of the connection requests distributes the load to avoid overburdening a single listener.

In addition to load balancing, clients can also specify that their connection request automatically fails over to a specific listener if a connection cannot be made with the listener chosen at random. A connection could fail either because the specified listener is not up or because the instance is not up and the listener therefore cannot accept the connection.

Configuring Client Load and Connection Load Balancing

To enable client load balancing, configure a service in your initialization parameter file and in the tnsnames.ora file. To do this, set the LOAD_BALANCE parameter to ON, YES, or TRUE and provide the same service name in the connect descriptor.

Note: Oracle Net uses the PMON process to automatically register service information. Therefore, you do not need to modify a listener.ora file with static instance information.

For connection load balancing, connections to the dispatchers on each node are based on the number of active connections. Oracle Net assigns new connections to the node that has the lowest processing load and fewest connections. If you have configured shared servers, then Oracle Net connects to the least loaded dispatcher.

Note: Clients must be connected to server machines in a scalable manner. This means that your network must also be scalable!

See Also: Oracle9i Net Services Administrator's Guide for additional conceptual and configuration information about the features described in this section

Enhanced Network Scalability and the Shared Server Feature

The shared server enables enhanced scalability in that for a given amount of memory you can support more users than when using dedicated servers. With shared server, the incremental memory cost as you add a user is less than when you use a dedicated server.

An increasing number of Oracle9i features require the shared server such as:

• Oracle9i JServer
• Connection Pooling
• Connection Concentration Feature
• Advanced Queueing

Service Registration and Shared Server Functionality

An important feature of shared server is service registration. This feature provides the listener with at least one service name and instance name as well as the network addresses of the database. It also provides information about the current state and load of all instances and shared server dispatchers. With this information, the listener forwards client connection requests to the appropriate dispatchers and dedicated servers.

Because this information is registered with the listener, you do not need to configure the listener.ora file with static database service information. Service registration also extends benefits to connection load balancing which is a feature of the shared server.

Note: Service registration is also available in dedicated servers. However, dedicated servers do not provide the same scalability as shared servers.

Operating System Scalability

The scalability of your Real Application Clusters database also depends on your operating system's scalability. Software scalability can be an important issue if one node is a shared memory system--that is, a system where multiple CPUs connect to a symmetric multiprocessor with a single memory location. Methods of synchronization in the operating system can determine the scalability of the system. In asymmetrical multiprocessing, for example, only a single CPU can handle I/O interrupts.

The next part of this book, Part II, provides detail about how the Global Cache and Global Enqueue Services coordinate resources within Real Application Clusters.