0056-0058

Previous Table of Contents Next

Page 56

and locks a row, the row remains locked for a user attempting to make a change on another instance. Other users can always query the rows regardless of how the rows are locked by other users.

You can initiate up to 10 LCK background processes to reduce the bottleneck of synchronizing locking, but one is usually more than enough.

You should not initiate the LCK background processes unless you're implementing a parallel server ( multi-instance ) setup of Oracle.

SQL*Net Listener

The SQL*Net Listener is a process running on the machine that routes requests coming in from client machines through to the correct Oracle instance. It communicates with the underlying networking software to route requests to and from the database server and the client machine (whether that client machine is a machine running an Oracle tool or even another database server).

For example, the communications between a client machine running Oracle Forms on a PC with DOS and Windows and a database server on a UNIX machine with TCP/IP as the networking protocol would involve the following major steps:

1. The client machine sends the SQL statement execution request to the UNIX database server machine.
2. The non-Oracle TCP/IP listener process picks up the request and recognizes it as a request for Oracle.
3. The request is sent to the Oracle SQL*Net listener, which routes the request to the correct instance on the machine. (The machine might be running many instances for many different databases.)
4. A process on the instance executes the statement.
5. The results are then sent back up the communications link to the client machine.

The SQL*Net listener is not related to the instance itself, but is system wide and will process requests for all instances running on the machine. You can initiate more than one SQL*Net listener, but this is uncommon.

User Processes

User processes logically consist of two halves : the Oracle server code, which translates and executes SQL statements and reads the database files and memory areas, and the tool-specific code, which is the executable code for the tool that is used. The server code is the same regardless of the tool that is executing the SQL statement; the same steps are involved. The server code is sometimes known as the Oracle kernel code.

You can configure the user processes in Oracle three different ways, all of which could coexist for the same instance. These three configurations are single task, dedicated server, or multithreaded server.

Page 57

Single Task

In the single-task configuration, the tool-specific code and database server code are both configured into one process running on the machine. Each connection to the database has one user process running on the machine. This is common on VAX VMS platforms without a client/server environment.

Dedicated Server Processes

In the dedicated server configuration (also known as two-task or running with shadow processes), the two parts of a user process are implemented as two separate processes running on the machine. They communicate with each other using the machine's interprocess communication mechanisms. Each connection to the database has two processes running on the machine. The Oracle kernel software in one process is sometimes called the shadow process.

This configuration is common for UNIX platforms because the operating system cannot (in some implementations of UNIX) protect the Oracle code and memory areas from the application code. It is also common for client/server configurations in which the server code resides on the server machine and the tool-specific code runs on the client machine with communication over a network. The way the two component parts of one logical process communicate is fundamentally the same as if one process were implemented on the same machine ”except that the two halves of the logical process happen to reside on two machines and communicate over the network using SQL*Net rather than the interprocess communication mechanisms of the operating system.

The dedicated server configuration can be wasteful because memory is allocated to the shadow process and the number of processes that must be serviced on the machine increases , even when the user is not making any database requests. The dedicated server (shadow process) will only process requests from one associated client process.

MTS ”The Multithreaded Server

The multithreaded server configuration enables one Oracle server process to perform work for many user processes. This overcomes the drawbacks of the dedicated server configuration. It reduces the number of processes running and the amount of memory used on the machine and can improve system performance. The multithreaded server introduces two new types of system processes that support this part of the architecture.

Using one of the shared server processes that comes as part of the multithreaded server configuration is not appropriate when a user process is making many database requests (such as an export backup of the database); for that process, you could use a dedicated server. A mixture of both configurations can coexist.

Dispatchers

One or more dispatcher processes retrieves requests for the client processes from the SQL*Net Listener and routes the request to one of the shared server processes. The SQL*Net Listener is required for the multithreaded server configuration, even if no networking is involved.

Page 58

You must configure at least one dispatcher for each network protocol that is used to route requests to the instance. The number of dispatchers configured does not increase if the system load increases because the dispatchers are only providing the routing. The actual work is done by the shared servers.

NOTE

The multithreaded server requires SQL*Net version 2 or later, even if both the dispatcher and the user processes are running on the same machine.

Shared Servers

The shared servers provide the same functionality as the dedicated server processes and contain the Oracle server code that performs the work for the client. They can service requests from many different user processes. The actual shared server used might differ from one call to another so that no user process can monopolize any one particular shared server process. Oracle uses an area in the SGA for messaging between the different processes involved.

The number of shared server processes is automatically increased (or decreased to an initial number defined by the database administrator) according to the system activity.

NOTE

The number of shared servers is increased or decreased automatically, but the number of dispatchers is not.

Oracle Memory

This section discusses how Oracle uses the machine's memory. Generally, the greater the real memory available to Oracle, the quicker the system runs.

System Global Area (SGA)

The system global area, sometimes known as the shared global area, is for data and control structures in memory that can be shared by all the Oracle background and user processes running on that instance. Each Oracle instance has its own SGA; in fact, the SGA and background processes is what defines an instance. The SGA memory area is allocated when the instance is started, and it's flushed and deallocated when the instance is shut down.

The contents of the SGA are divided into three main areas: the database buffer cache, the shared pool area, and the redo cache. The size of each of these areas is controlled by parameters in the INIT.ORA file. The bigger you can make the SGA and the more of it that can fit into the machine's real memory (as opposed to virtual memory), the quicker your instance will run. Figure 4.4 shows the Oracle SGA in memory.

Previous Table of Contents Next