Database Reference
In-Depth Information
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
sga_target big integer 1520M
Now when we look at the SGA components:
SYS@ORA12CR1> select component, granule_size from v$sga_dynamic_components;
COMPONENT GRANULE_SIZE
---------------------------------------------------------------- ------------
shared pool 16777216
large pool 16777216
java pool 16777216
streams pool 16777216
DEFAULT buffer cache 16777216
KEEP buffer cache 16777216
RECYCLE buffer cache 16777216
DEFAULT 2K buffer cache 16777216
DEFAULT 4K buffer cache 16777216
DEFAULT 8K buffer cache 16777216
DEFAULT 16K buffer cache 16777216
DEFAULT 32K buffer cache 16777216
Shared IO Pool 16777216
Data Transfer Cache 16777216
ASM Buffer Cache 16777216
15 rows selected.
As you can see, at 1.5GB of SGA, my pools will be allocated using 16MB granules, so any given pool size will be
some multiple of 16MB.
With this in mind, let's look at each of the major SGA components in turn.
Fixed SGA
The
fixed SGA
is a component of the SGA that varies in size from platform to platform and from release to release.
It is “compiled” into the Oracle binary itself at installation time (hence the name “fixed”). The fixed SGA contains a
set of variables that point to the other components of the SGA, as well as variables that contain the values of various
parameters. The size of the fixed SGA is something over which we have no control, and it is generally very small. Think
of this area as a “bootstrap” section of the SGA—something Oracle uses internally to find the other bits and pieces of
the SGA.
Redo Buffer
The
redo buffer
is where data that needs to be written to the online redo logs will be cached temporarily, before it is
written to disk. Since a memory-to-memory transfer is much faster than a memory-to-disk transfer, use of the redo log
buffer can speed up database operation. The data will not reside in the redo buffer for very long. In fact,
LGWR
initiates
a flush to disk of this area in one of the following scenarios:
•
Every three seconds
COMMIT
or
ROLLBACK
is issued
•
Whenever a
