Database Reference
In-Depth Information
The large pool is not mandatory when using shared server connections, but it is highly recommended. If you
don't have a large pool and use a shared server connection, the allocations come out of the shared pool as they always
did in Oracle 7.3 and before. This will definitely lead to degraded performance over some period of time and should
be avoided. The large pool will default to some size if the parameter
DBWR_IO_SLAVES
or
PARALLEL_MAX_SERVERS
is set
to some positive value. You should set the size of the large pool manually if you are using a feature that employs it.
The default value typically will not be appropriate for your situation.
Java Pool
The Java pool was added in version 8.1.5 of Oracle to support running Java in the database. If you code a stored
procedure in Java, Oracle will use this chunk of memory when processing that code. The parameter
JAVA_POOL_SIZE
is used to fix the amount of memory allocated to the Java pool for all session-specific Java code and data.
The Java pool is used in different ways, depending on the mode in which the Oracle server is running. In
dedicated server mode, the Java pool includes the shared part of each Java class, which is actually used per session.
These are basically the read-only parts (execution vectors, methods, etc.) and are about 4KB to 8KB per class. Thus,
in dedicated server mode the total memory required for the Java pool is quite modest and can be determined based
on the number of Java classes you'll be using. Note that none of the per-session state is stored in the SGA in dedicated
server mode, as this information is stored in the UGA and, as you will recall, the UGA is included in the PGA in
dedicated server mode.
When connecting to Oracle using a shared server connection, the Java pool includes both of the following:
•
The shared part of each Java class.
•
Some of the UGA used for per-session state of each session, which is allocated from the Java
pool within the SGA. The remainder of the UGA will be located as usual in the shared pool, or
if the large pool is configured, it will be located there instead.
As the total size of the Java pool is fixed in Oracle9
i
and before, application developers will need to estimate the
total requirement of their applications and multiply this estimate by the number of concurrent sessions they need to
support. This number will dictate the overall size of the Java pool. Each Java UGA will grow or shrink as needed, but
bear in mind that the pool must be sized such that all UGAs combined can fit in it at the same time. In Oracle 10
g
and
above, this parameter may be modified, and the Java pool may grow and shrink over time without the database being
restarted.
Streams Pool
The Streams pool is an SGA structure introduced in Oracle 10
g
. Oracle products that use the Streams pool include
Oracle GoldenGate, XStream, Oracle Streams, Oracle Advanced Queuing, and Oracle Data Pump.
The size of the Streams pool is governed by setting the
STREAMS_POOL_SIZE
parameter. If
SGA_TARGET
is a non-
zero value, then automatic SGA memory management will use the setting of
STREAMS_POOL_SIZE
as a minimum value
for the Streams pool. If both the
SGA_TARGET
and
STREAMS_POOL_SIZE
are both set to zero, then up to 10 percent of the
shared pool is used by the Streams pool.
Products that use the Streams pool will buffer queue messages. Instead of using permanent disk-based queues,
with their attendant overhead, these features use in-memory queues. If these queues fill up, they eventually spill
over to disk. If the Oracle instance with the memory queue fails for some reason, due to an instance failure (software
crash), power failure, or whatever, these in-memory queues are rebuilt from the redo logs.
The Streams pool is only important in systems using features (such as GoldenGate, Streams, and so on) that need
space in this memory area. In those environments, the
STREAMS_POOL_SIZE
should be set in order to avoid “stealing”
10 percent of the shared pool.
