Oracle Essentials Oracle Database 11g (16 page)

The Oracle Application Server, which is part of the overall Oracle platform, is designed to act as this middle tier. Application Server works seamlessly with the Oracle database and shares some of the same technology. Application Server is described

in more detail in Chapter 15.

Figure 3-5
illustrates users connecting to an Oracle instance to access a database in both two-tier and three-tier configurations, involving local and network communication. This figure highlights the server process connection models as opposed to the interaction of the background processes. There is a traditional two-tier client/server connection on the left side, a three-tier connection with an application server on the right side, and a local client connection in the middle of the figure. The two-tier and three-tier connections use a network to communicate with the database, while the local client uses local IPC.

Accessing a Database

|

71

SGA

Database Buffer

Redo Log

Shared Pool

Cache

Buffer

Client

NETWORK

NETWORK

Local

Local

Application

Server

Client

Server

Server

Server

IPC

Client

Datafiles

Figure 3-5. Accessing a database

Oracle Net and Establishing Network Connections

The server processes shown in
Figure 3-5
are connected to the client processes using some kind of network. How do client processes get hooked up with Oracle server processes to begin working?

The matchmaker that arranges marriages between Oracle clients and server processes is called the Oracle Net Listener. The Listener “listens” for incoming connection requests for one or more instances. The Listener is not part of the Oracle instance—

it directs connection requests to the instance. The Listener is started and stopped independently of the instance. If the Listener is down and the instance is up, clients accessing the database over a network cannot find the instance because there is no Listener to guide them. If the Listener is up and the instance is down, there is nowhere to send clients.

The Listener’s function is relatively simple:

1. The client contacts the Listener over the network.

2. The Listener detects an incoming request and introduces the requesting client to an Oracle server process.

3. The Listener introduces the server to the client by letting each know the other’s network address.

4. The Listener steps out of the way and lets the client and server communicate directly.

72

|

Chapter 3: Installing and Running Oracle

Once the client and the server know how to find each other, they communicate directly. The Listener is no longer required.

Figure 3-6
illustrates the steps outlined above for establishing a networked connection. Network traffic appears as dotted lines.

Figure 3-6. Connecting with the Oracle Net Listener

The Shared Server/Multi-Threaded Server

The server processes shown in the diagram are
dedicated
; they serve only one client process. So, if an application has 1,000 clients, the Oracle instance will have 1,000

corresponding server processes. Each server process uses system resources such as the memory and the CPU. Scaling to large user populations can consume a lot of system resources. To support the ever-increasing demand for scalability, Oracle introduced the Multi-Threaded Server (MTS) in Oracle7, known as the
shared server
since Oracle9
i
.

Shared servers allow the Oracle instance to share a set of server processes across a larger group of users. Instead of each client connecting to and using a dedicated server, the clients use shared servers, which can significantly reduce the overall resource requirements for serving large numbers of users.

In many systems there are times when the clients aren’t actively using their server process, such as when users are reading and absorbing data retrieved from the database. When a client is not using its server process in the
dedicated model
, that server
Accessing a Database

|

73

process still has a hold on system resources even though it isn’t doing any useful work. In the
shared server model
, the shared server can use the resources of an inac-tive client to do work for another client process.

You don’t have to make a mutually exclusive choice between shared server processes and dedicated server processes for an Oracle instance. Oracle can mix and match dedicated and shared servers, and clients can connect to one or the other. The choice is based on your Oracle Net configuration files. In the configuration files there will be one service name that leads the client to a dedicated server, and another for connecting via shared servers. The Oracle Net manuals provide the specific syntax for this configuration.

The type of server process a client is using is transparent to the client. From a client perspective, the multithreading or sharing of server processes happens “under the covers,” on the database server. The same Listener handles dedicated and multithreaded connection requests.

The steps the Listener takes in establishing a shared server connection are a little different and involve some additional background processes for the instance dispatchers and the shared servers themselves:

Dispatchers

In the previous description of the Listener, you saw how it forms the connection between a client and server process and then steps out of the way. The client must now be able to depend on a server process that is always available to complete the connection. Because a shared server process may be servicing another client, the client connects to a dispatcher, which is always ready to receive any client request. There are separate dispatchers for each network protocol being used (e.g., dispatchers for TCP/IP, etc.). The dispatchers serve as surrogate dedicated servers for the clients. Clients directly connect to their dispatchers instead of to a server. The dispatchers accept requests from clients and place them in a request queue, which is a memory structure in the SGA. There is one request queue for each instance.

Shared servers

The shared server processes read from the request queue, process the requests, and place the results in the response queue for the appropriate dispatcher. There is one response queue for each dispatcher. The dispatcher then reads the results from the response queue and sends the information back to the client process.

There is a pool of dispatchers and a pool of shared servers. Oracle starts a certain number of each based on the initialization parameter SHARED_SERVERS that specifies the minimum number of shared servers. Oracle can start additional shared servers up to the value of an optionally specified initialization parameter MAX_

SHARED_SERVERS. If Oracle starts additional processes to handle a heavier request load and the load dies down again, Oracle gradually reduces the number of processes to the floor specified by SHARED_SERVERS.

74

|

Chapter 3: Installing and Running Oracle

The following steps show how establishing a connection and using shared server processes differ from using a dedicated server process:

1. The client contacts the Listener over the network.

2. The Listener detects an incoming request and, based on the Oracle Net configuration, determines that it is for a multithreaded server. Instead of handing the client off to a dedicated server, the Listener hands the client off to a dispatcher for the network protocol the client is using.

3. The Listener introduces the client and the dispatcher by letting each know the other’s network address.

4. Once the client and the dispatcher know where to find each other, they communicate directly. The Listener is no longer required. The client sends each work request directly to the dispatcher.

5. The dispatcher places the client’s request in the request queue in the SGA.

6. The next available shared server process reads the request from the request queue and does the work.

7. The shared server places the results for the client’s request in the response queue for the dispatcher that originally submitted the request.

8. The dispatcher reads the results from its queue.

9. The dispatcher sends the results to the client.

Figure 3-7
illustrates the steps for using the shared servers. Network traffic appears as dotted lines.

Figure 3-7. Connecting with the Oracle Net Listener (shared servers)
Accessing a Database

|

75

Session memory for shared server processes versus dedicated server processes
There is a concept in Oracle known as
session memory
or
state
. State information is basically data that describes the current status of a session in Oracle. For example, state information contains information about the SQL statements executed by the session. When youuse a dedicated server, this state is stored in the private memory used by the dedicated server. This works out well because the dedicated server works with only one client. The term for this private memory is the Program Global Area (PGA).

If you’re using the shared servers, however, any server can work on behalf of a specific client. The session state cannot be stored in the PGA of the shared server process. All servers must be able to access the session state because the session can migrate between different shared servers. For this reason, Oracle places this state information in the System Global Area (SGA).

All servers can read from the SGA. Putting the state information in the SGA allows a session and its state to move from one shared server to another for processing different requests. The server that picks up the request from the request queue simply reads the session state from the SGA, updates the state as needed for processing, and puts it back in the SGA when processing has finished.

The request and response queues, as well as the session state, require additional memory in the SGA, so in older Oracle releases, youwould allocate more memory manually if you were using shared servers. By default, the memory for the shared server session state comes from the shared pool. Alternatively, youcould also configure something called the
large pool
as a separate area of memory for shared servers.

(We introduced the large pool in
Chapter 2
in the
“Memory Structures for an

Instance”
section.) Using the large pool memory avoided the overhead of coordinat-ing memory usage with the shared SQL, dictionary caching, and other functions of the shared pool. This allowed memory management from the large pool and avoided competing with other subsystems for space in and access to the shared pool. Since Oracle Database 10
g,
shared memory is automatically managed by default. Oracle Database 11
g
introduced automated memory management of the SGA and PGA size by default when you set the MEMORY_TARGET initialization parameter.

Data dictionary information about the shared server

The data dictionary, which we introduced in
Chapter 2,
also contains information about the operation of the MTS in the following views:

V$SHARED_SERVER_MONITOR

This view contains dynamic information about the shared servers, such as high-water marks for connections and how many shared servers have been started and stopped in response to load variations.

76

|

Chapter 3: Installing and Running Oracle