Oracle 8i | Oracle 9i | Oracle 10g | Oracle 11g | Oracle 12c | Miscellaneous | PL/SQL | SQL | Oracle RAC | Oracle Apps | Linux

Scalable Session Management

Oracle9i includes a number of scalability improvements in relation to session management including:

Oracle Shared Server

Oracle Shared Server is the new name for Oracle Multi-threaded Server (MTS) and includes several new features.

In MTS, clients contacted the listener asking for a connection. The listener sent the address of a dispatcher to the client, who then contacted the dispatcher directly to confirm the connection. In Oracle Shared Server the client contacts the listener to ask for a connection resulting in a connection socket being established between the listener and the client. The listener then hands this socket to the relevant dispatcher to allow instant communication between the client and the dispatcher. This process is called a Direct Handoff.

Prior to Oracle9i, dispatchers handled network and database events separately. Network events were handled using the UNIX system call poll() via the network services, while database event were handled by the Virtual Operating System (VOS), an internal abstraction layer not visible to the DBA. Polling and coordinating both event models wasted time. In Oracle9i the Common Event Model has poll() incorporated into the VOS layer on the database so there is no need to poll the network services anymore.

Performance Manager, part of the Diagnostics Pack in Oracle Enterprise Manager (OEM), provides graphical monitoring the shared server. This can be done with an overall view, or detailed to the level of dispatchers, shared server processes and listeners. In addition Performance Manager can view the SQL statements fired for each session and provide help in tuning the Shared Server parameters.

Dedicated External Procedure Agents

In Oracle8i external procedures are run using EXTPROC, with each client that calls an external procedure getting their own external procedure process. This can lead to overloading which affects scalability.

Oracle9i makes up for this shortfall by the addition of dedicated external procedure agents which can run on servers other than the database server, thereby spreading the load. The default server is still EXTPROC, but individual PL/SQL calls can specify the agent they wish to use. Calls to agents and EXTPROC can occur via database links.

Multiple sessions can use external procedures via a single dedicated agent which decreases the load on the system, thereby increasing the scalability. For robustness external procedure calls can be split into functional areas with each getting it's own dedicated agent. This way bad code in one functional area that crashes the agent will not affect other functional areas.

To call a remote agent the library must be created using the following syntax.

CREATE OR REPLACE DATABASE LINK agent_link USING 'agent_tns_alias';

CREATE OR REPLACE LIBRARY plib1 IS
'${EP_LIB_HOME}/plib1.so'
AGENT 'agent_link';

Note, the AGENT clause specifies the database link for the remote server. The environment variable reference is the same in UNIX and NT, but the '/' must be reversed for NT.

Now the library is created procedures can be defined to access the shared library.

CREATE PROCEDURE sum_rates(...) IS EXTERNAL
LANGUAGE C NAME "RATES_C" LIBRARY plib1;

Transaction support for external procedures is introduced in Oracle9i. Each transaction system must have a transaction server (XA) library, which is linked with a dedicated agent. This feature is not exposed in this release but may be in future releases.

Multithreaded Heterogeneous Service (HS) Agent

Heterogeneous Services allow Oracle to access non-Oracle databases and services via SQL and PL/SQL. In Oracle8 and Oracle8i each user accessing such resources via a database link was assigned a separate process per database link. The process would remain until the user process ended, or the database link was closed. Just as the Shared Server reduces excess user processes, so does the Multithreaded Heterogeneous Service Agent. Infact, the architecture is almost identical and is used by both Generic Connectivity (ODBC, OLE DB) and Oracle Transparent Gateways (brand specific connection agents) to allow multi-threaded connectivity.

Essentially, each request is passed to a dispatcher which puts it on a request queue. A task process reads the request from the queue, processes it and puts the results on a results queue. The dispatcher then reads the results and passes it back to the requestor. Once connected, all requests for a session are passed through the same dispatcher. Multiple task processes can use the same connection to the non-Oracle datasource.

In addition to the dispatcher and task threads there is a single Monitor thread. This is the equivalent of PMON and controls thread creation, monitoring and cleanup of aborted threads.

Only a single agent can be started per SID. The agent process must be prestarted using the AGTCTL utility. When the agent process is started it creates the Monitor thread. This subsequently creates the dispatcher and task threads and registers the dispatcher threads with all the listeners that are handling connections to this agent. If the listener recieves a request for a non-Oracle resource it passes it directly to the relevant agent process.

Since the new architecture only uses a single process with multiple threads it is significantly more efficient than the previous multi-process version. Added to that, the number of threads can be significantly lower than the total number of user connections.

The memory management is thread-safe so individual sessions cannot overwrite each others data. The initialization parameters for the HS agents are:

Parameter Usage
max_dispatchers Maximum number of dispatchers.
tcp_dispatchers Number of dispatchers listening on TCP, the rest will use IPC.
max_task_threads Number of task threads.
listener_address Address on which the listener is listening.
shutdown_address Address on which the agent should listen for shutdown messages from the AGTCTL utility.

OCI Connection Pooling

Maintaining dedicated connections for each user has an impact on the scalability of the system. The time to create each connection and the memory associated it limit the number of simultaneous users. For this reason Oracle9i has extended connection pooling into the Oracle Call Interface (OCI) so it can be used by application and mail servers. The benefits of OCI connection pooling are:

The following steps are required to implement OCI connection pooling:

Action OCI Call
Allocate the pool handle OCIHandleAlloc()
Create the connection pool OCIConnectionPoolCreate()
Log on to the database OCILogon2()
Call executions Various
Log off from the database OCILogoff()
Destroy the connection pool OCIConnectionPoolDestroy()
Free the pool handle OCIHandleFree()

Core Library Improvements

The libraries that make up the Oracle kernal have been revised to make them more modular and self-contained. Smaller modules mean that less memory is required by applications when loading specific functionality. Being more self-contained means that less supporting libraries are needed to support each functional element. The combination of the two mean that overall memory usage is improved since unused features are not loaded into memory.

Hope this helps. Regards Tim...

Back to the Top.