Databases Reference
In-Depth Information
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 being executed by the ses‐
sion. When you use 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, you would 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, you could 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 section
“Memory Structures for an Instance” on page
58
.) Using the large pool memory avoided the overhead of coordinating 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 auto‐
mated memory management of the SGA and PGA size by default when you set the
MEMORY_TARGET initialization parameter, and Oracle Database 12
c
enhanced this
automatic memory management of the PGA.
Data dictionary information about the shared server
The data dictionary, which we introduced in
Chapter 2
, also contains information about
the operation of shared servers 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.
