3 Connectivity Concepts

Database Services

An Oracle database is represented to clients as a service; that is, the database performs work on behalf of clients. A database can have one or more services associated with it.

Figure 3-1 shows two databases, each with its own database service for intranet clients. One service, sales.us.acme.com, enables salespersons to access the sales database. Another service, finance.us.acme.com, enables financial analysts to access the finance database.

Figure 3-1 One Service for Each Database

Description of "Figure 3-1 One Service for Each Database"

The sales and finance databases are each identified by a service name, sales.us.acme.com and finance.us.acme.com. The service name is specified by the SERVICE_NAMES parameter in the initialization parameter file (init.ora). The service name defaults to the global database name, a name comprising the database name (DB_NAME parameter) and domain name (DB_DOMAIN parameter). In the case of sales.us.acme.com, sales is the database name and us.acme.com is the domain name.

A database can have multiple services associated with it. Figure 3-2 shows one database that has two different services for Web clients. One service, book.us.acme.com, is dedicated to clients making book purchases. The other service, soft.us.acme.com, is dedicated to clients making software purchases.

Figure 3-2 Multiple Services Associated with One Database

Description of "Figure 3-2 Multiple Services Associated with One Database"

Having multiple services associated with one database enables the following functionality:

• A single database can be identified in a number of different ways by different clients.

• A database administrator can limit or reserve system resources. This level of control enables better allocation of resources to clients requesting one of these services.

Database Instances

A database has at least one instance. An instance is comprised of a memory area called the System Global Area (SGA) and Oracle processes. The memory and processes of an instance efficiently manage the associated database's data and serve the database users.

Figure 3-3 shows two instances, sales and finance, associated with their respective databases.

Figure 3-3 One Instance for Each Database

Description of "Figure 3-3 One Instance for Each Database"

Like services, instances are identified by an instance name, sales and finance in this example. The instance name is specified by the INSTANCE_NAME parameter in the initialization parameter file. The instance name defaults to the Oracle System Identifier (SID) of the instance.

Some hardware architectures allow multiple computers to share access to data, software, or peripheral devices. Oracle Real Application Clusters can take advantage of such architecture by running multiple instances on different computers that share a single physical database.

Figure 3-4 shows an Oracle Real Application Clusters configuration. In this example, two instances, sales1 and sales2, are associated with one database service, sales.us.acme.com.

Figure 3-4 Multiple Instances Associated with a Database

Description of "Figure 3-4 Multiple Instances Associated with a Database"

Connect-Time Failover

The connect-time failover enables clients to connect to another listener if the initial connection to the first listener fails. The number of listener protocol addresses determines how many listeners are tried. Without connect-time failover, Oracle Net attempts a connection with only one listener.

Transparent Application Failover

The Transparent Application Failover (TAF) feature is a runtime failover for high-availability environments, such as Oracle Real Application Clusters. TAF fails over and reestablishes application-to-service connections. It enables client applications to automatically reconnect to the database if the connection fails and, optionally, resume a SELECT statement that was in progress. The reconnection happens automatically from within the Oracle Call Interface (OCI) library.

Client Load Balancing

The client load balancing feature enables clients to randomize connection requests among the listeners. Oracle Net progresses through the list of protocol addresses in a random sequence, balancing the load on the various listeners. Without client load balancing, Oracle Net progresses through the list of protocol addresses sequentially until one succeeds.

Connection Load Balancing

The connection load balancing feature improves connection performance by balancing the number of active connections among multiple dispatchers. In a single-instance environment, the listener selects the least loaded dispatcher to handle the incoming client requests. In an Oracle Real Application Clusters environment, connection load balancing also has the capability to balance the number of active connections among multiple instances.

Due to dynamic service registration, a listener is always aware of all instances and dispatchers regardless of their location. Depending on the load information, a listener decides which instance and, if shared server is configured, to which dispatcher to send the incoming client request.

In a shared server configuration, a listener selects a dispatcher in the following order:

1. Least-loaded node

2. Least-loaded instance

3. Least-loaded dispatcher for that instance

In a dedicated server configuration, a listener selects an instance in the following order:

1. Least loaded node

2. Least loaded instance

If a database service has multiple instances on multiple nodes, the listener chooses the least loaded instance on the least loaded node. If shared server is configured, then the least loaded dispatcher of the selected instance is chosen.

Dispatchers

The shared server architecture uses a dispatcher process to direct client connections to a common request queue. An idle shared server process from a shared pool of server processes picks up a request from the common queue. This approach enables a small pool of server processes to serve a large number of clients. A significant advantage of the shared server model over the dedicated server model is reduced system resources, enabling support of an increased number of users.

The listener uses the dispatcher as a type of service handler to which it can direct client requests. When a client request arrives, the listener performs one of the following actions:

• Hands the connection request directly to a dispatcher.

• Issues a redirect message to the client, containing the protocol address of a dispatcher. The client then terminates the network session to the listener and establishes a network session to the dispatcher, using the network address provided in the redirect message.

The listener uses direct hand off whenever possible. Redirect messages are used, for example, when dispatchers are remote to the listener.

Figure 3-5 shows the listener handing a connection request directly off to a dispatcher.

1. The listener receives a client connection request.

2. The listener hands the connect request directly to the dispatcher.

3. The client is now connected to the dispatcher.

Figure 3-5 Direct Hand-Off to a Dispatcher

Description of "Figure 3-5 Direct Hand-Off to a Dispatcher"

Figure 3-6 shows the role of a dispatcher in a redirected connection.

1. The listener receives a client connection request.

2. The listener provides the location of the dispatcher to the client in a redirect message.

3. The client connects directly to the dispatcher.

Figure 3-6 Redirected Connection to a Dispatcher

Description of "Figure 3-6 Redirected Connection to a Dispatcher"

Dedicated Server Processes

In a dedicated server configuration, the listener starts a separate dedicated server process for each incoming client connection request dedicated to servicing the client. Once the session is complete, the dedicated server process terminates. Because a dedicated server process has to be started for each connection, this configuration may require more system resources than shared server configurations.

A dedicated server process is a type of service handler that the listener starts when it receives a client request. To complete a client/server connection establishment, one of the following actions occurs:

• The dedicated server inherits the connection request from the listener.

• The dedicated server informs the listener of its listening protocol address. The listener passes the protocol address to the client in a redirect message and terminates the connection. The client connects to the dedicated server directly using the protocol address.

  Note:

  One of the options is selected based on the operating system and the transport protocol.

If the client and database server exist on the same computer, a client connection can be passed directly to a dedicated server process without going through the listener. The application initiating the session spawns a dedicated server process for the connection request. This happens automatically if the application that is used to start the database is on the same computer as the database.

Figure 3-7 shows the listener passing a client connection request to a dedicated server process.

1. The listener receives a client connection request.

2. The listener starts a dedicated server process, and the dedicated server inherits the connection request from the listener.

3. The client is now connected directly to the dedicated server.

Figure 3-7 Connection to a Dedicated Server Process

Description of "Figure 3-7 Connection to a Dedicated Server Process"

Figure 3-8 shows the role of a dedicated server in a redirected connection.

1. The listener receives a client connection request.

2. The listener starts a dedicated server process.

3. The listener provides the location of the dedicated server process to the client in a redirect message.

4. The client connects directly to the dedicated server.

Figure 3-8 Redirected Connection to a Dedicated Server Process

Description of "Figure 3-8 Redirected Connection to a Dedicated Server Process"

Database Resident Connection Pooling

Database resident connection pooling is useful for applications deployed as either multiple processes, on multiple hosts, or both (such as Apache/PHP) that must maintain persistent connections to the database, and server resources (such as memory) must be optimized. It provides pooling dedicated connections across client applications and processes.

Clients obtaining connections out of the database resident connection pool are persistently connected to a background process—the connection broker—instead of to the dedicated servers. The connection broker implements the pool functionality and does the multiplexing of inbound connections from the clients to a pool of dedicated servers with sessions.

When a client needs to perform database work, the connection broker picks up a dedicated server from the pool and assigns it to the client. Subsequently, the client is directly connected to the dedicated server until the request is served. After the server finishes processing the client request, the server goes back into the pool and the connection from the client is restored to the connection broker.

Figure 3-9 graphically illustrates the process.

Figure 3-9 Pool of Dedicated Server Processes Handling Connections Through the Connection Broker Process

Description of "Figure 3-9 Pool of Dedicated Server Processes Handling Connections Through the Connection Broker Process"