|Oracle9i Real Application Clusters Concepts
Release 2 (9.2)
Part Number A96597-01
This chapter provides detail about the scalability features of Real Application Clusters and includes the following topics:
You can implement Real Application Clusters using several features that enhance application performance and maintain high availability levels. These features:
If you install Real Application Clusters with one of the preconfigured databases, then the Database Configuration Assistant (DBCA) automatically configures most of these features.
This section describes why all system types benefit from Real Application Clusters. It includes the following topics:
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 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.
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.
Implementing cluster databases requires optimal scalability on the following levels as described in this section:
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.
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.
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:
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.
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.
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.
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
TRUE and provide the same service name in the connect descriptor.
Oracle Net uses the PMON process to automatically register service information. Therefore, you do not need to modify a
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.
Clients must be connected to server machines in a scalable manner. This means that your network must also be scalable!
Oracle9i Net Services Administrator's Guide for additional conceptual and configuration information about the features described in this section
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:
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.
Service registration is also available in dedicated servers. However, dedicated servers do not provide the same scalability as shared servers.
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.