Previous | Table of Contents | Next

Page 479

The SQLNET.ENCRYPTION_TYPES_SERVER and SQLNET.ENCRYPTION_TYPES_CLIENT parameters specify the encryption algorithms the client or server machine can use. If more than one algorithm is specified, the machine will attempt each one, starting from the first to the last. The actual algorithm used in the session will be determined from the negotiation between the client and server. If an algorithm cannot be negotiated because the server and the client do not have an algorithm in common, the connection will fail.

Valid encryption types are:

To specify the checksum behavior, the SQLNET.CRYPTO_CHECKSUM_SERVER and SQLNET.CRYPTO_CHECKSUM_CLIENT parameters are used. Like the encryption parameters, these parameters will accept ACCEPTED, REJECTED, REQUESTED, and REQUIRED as valid values, and behave in the same way when negotiating a connection.

There is one final set of parameters: SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER and SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT. These parameters will specify the type of algorithm used to produce the checksum values. Currently, only MD5 is supported as a valid value for these parameters.

Finally, the SQLNET.CRYPTO_SEED parameter is configured on the client computer to seed the cryptographic keys. This is an alphanumeric value from 10 to 70 characters long. The longer and more random this series of digits is, the stronger the checksum key is. You must specify a value for this parameter when using encryption or checksums.

Understanding the Multi-Threaded Server

By default, users connect to the Oracle database server through the use of dedicated server processes. This means that for each user connection, there is an associated process that handles the work for that user process, such as loading requested data from the datafiles into the data block buffer, and returning the results of database queries to the user. This is the fastest and simplest way to provide connectivity into the database. However, in situations where hundreds or even thousands of users are connected simultaneously, the overhead involved in maintaining these dedicated server processes is prohibitive. Also, the dedicated server processes consume the same amount of resources on the database server whether they are active or idle. If, as in many cases, you have a large population of users connected to the database but actually accessing data from the database infrequently, the server resources tied up in maintaining these dedicated server processes are wasted. It is here that the Multi-Threaded Server (MTS) can save the day.

Page 480

In simplest terms, the Multi-Threaded server allows many user sessions to share a group of server processes, thereby reducing the overhead resources necessary to support a large simultaneous user base. This structure will also allow you to reduce the overall idle time among these server sessions. For example, if you have one hundred simultaneous user connections, but on average ten are active at any one time, you can maximize your resources by allocating ten server processes for the users to use. This keeps ten server processes active at all times, rather than ten active and ninety idle processes when using dedicated server processes.

Multi-Threaded Server Architecture

When MTS is used, there are several differences in the architecture that need to be understood. If you recall from Chapter 5, "The Oracle Instance Architecture," when connecting to an Oracle database using dedicated server processes, the Listener connects the user session with a dedicated server process, who manages the user's connection to the Oracle database. In an MTS environment, the Listener's actions are slightly different. Instead of spawning and connecting the User session to a dedicated Server process, it passes the User process to one or more Dispatcher processes. These Dispatcher processes are responsible for placing the User processes commands into the Request Queue, as well as retrieving the results of User processes commands from the Response Queue. The Request and Response Queues are both held in the SGA.

The Shared Server processes do not communicate directly with the Dispatcher or the Server processes. Rather, they monitor the Request Queue, and when a new command is placed in the queue they read the command, process it by reading appropriate data blocks in the data block buffer and submitting the command to the database, and place the results in the Dispatcher's Response Queues. All Dispatchers place their requests into one Request Queue. Each Dispatcher also has its own Response Queue. The Shared Server processes ensure that the results of User commands are placed in the correct Response Queue for the Dispatcher that issued the command. In this way, the Shared Server processes can work very efficiently together by handling the requests from all User sessions, while the Dispatchers only have to retrieve and manipulate data for User sessions being handled by them.

Usage of the Multi-Threaded server also changes the allocation of memory to the SGA. Because there are no dedicated server processes, user session data and cursor state information is stored in the SGA, rather than the PGA. The SGA should be adjusted accordingly because of this. Note that this is not an additional cost of running MTS, but an adjustment of where the data is held in memory.

Configuring the Multi-Threaded Server

The Multi-Threaded server is configured largely through parameters contained in each databases init.ora file. The following are the parameters you configure to enable MTS:

MTS_SERVICE The name of the service the Dispatcher processes associ-
ate themselves with. The Listener will pass requests for a
service to the appropriate Dispatcher based on the value
of this parameter. Usually set to the value of the
database name (db_name init.ora parameter value).


Page 481

MTS_SERVERS Specifies the number of shared server processes to
create at instance startup.
MTS_MAX_SERVERS Specifies the maximum number of shared server processes
that will run at any one time. Shared server processes will
be allocated and destroyed depending on need, but their
number will never be greater than this number, or
lower than the value of MTS_SERVERS.
MTS_DISPATCHERS Defines the protocol and number of dispatchers to allocate
at instance startup. To specify multiple dispatchers
with different protocols, specify each protocol with
separate MTS_DISPATCHERS parameters.
MTS_MAX_DISPATCHERS Specifies the maximum number of dispatcher processes
that will run at any one time. Dispatcher processes will
be allocated and destroyed based on system load.
MTS_LISTENER_ADDRESS The address the dispatcher processes will listen at. This
is the same as the Listener address.

The MTS parameters from an example init.ora file are shown in Listing 20.2.

Listing 20.2INIT.ORA
MTS_SERVICE = PROD01          # Database name is PROD01.
MTS_SERVERS = 3                       # Start 3 shared server processes
at Âinstance start.
MTS_MAX_SERVERS = 10          # Never start more than 10 shared server 
Âprocesses. MTS_DISPATCHERS = "tcp,3" # Start 3 dispatchers that use the TCP/IP
Âprotocol. MTS_DISPATCHERS = "spx,1" # Start 1 dispatcher that uses SPX. MTS_MAX_DISPATCHERS = 10 # Never start more than 10 dispatcher processes. MTS_LISTENER_ADDRESS = "(address=(protocol=tcp)(address=dbserver)(port=1521))" MTS_LISTENER_ADDRESS = "(address=(protocol=spx)(service=novellserver))"

In addition to configuring the dispatchers and shared server processes, you can also control MTS behavior on the client. Because certain jobs cannot be run using a shared server process (such as direct load exports and SQL*Loader executions), and certain jobs perform much better using dedicated servers (such as batch or processing intensive jobs), you may want to force the usage of a dedicated server. You can do this globally on the client by setting the sqlnet.ora parameter USE_DEDICATED_SERVER to TRUE. This will force all SQL*Net connections made by the client to use a dedicated server. To specify the usage of a dedicated server for an individual TNS alias, set the tnsnames.ora file SERVER parameter to DEDICATED. For example, Listing 20.3 specifies two TNS aliases that connect to the same database. However, the second alias uses a dedicated server, while the first uses a shared.

Previous | Table of Contents | Next