2.3 The Components of an Instance
An Oracle instance
can be defined as an area of shared memory and a collection of
background processes. The area of shared memory for an instance is
called the System
Global Area, or SGA. The
SGA
is not really one large undifferentiated section of
memory�it's made up of various components that
we'll examine in Section 2.3.1. All the processes of an
instance�system processes and user processes�share the
SGA.
Prior to Oracle9i, the size of the SGA was set
when the Oracle instance was started. The only way to change the size
of the SGA or any of its components was to change the initialization
parameter and then stop and restart the instance. Since
Oracle9i, you can
change the size of the SGA or its components while the Oracle
instance is still running. Oracle9i introduced
the concept of the
granule,
which is the smallest amount of memory that you can add to or
subtract from the SGA.
The background processes interact with the operating system and each
other to manage the memory structures for the instance. These
processes also manage the actual database on disk and perform general
housekeeping for the instance.
There are other physical files that you can consider as part of the
instance as well:
- The instance initialization file
The initialization file
contains a variety of parameters that configure how the instance will
operate: how much memory it will use, how many users it will allow to
connect, to which database the instance actually provides access, and
so on. You can alter many of these parameters dynamically at either
the systemwide or session-specific level. Prior to
Oracle9i, the only initialization file was
called
INIT.ORA.
Oracle9i
introduced a file named
SPFILE
that performs the same function as the INIT.ORA
file but can also persistently store changes to initialization
parameters that have been made while Oracle is running.
SPFILE is a binary file that is kept on the
server machine, which eliminates the need for
INIT.ORA files on client machines. When an
instance of Oracle starts up, it first looks for
SPFILE and then for an
INIT.ORA file.
Oracle Database
10g's automated features reduce the number of
parameters requiring initial manual definition. Now, fewer than 40
parameters require manual definition.
- The instance configuration file
CONFIG.ORA
is an optional parameter file. You can include it if you want to
segregate a set of initialization parameters (for example, those used
for Real Application Clusters).
- The password file
Oracle can use an optional
password
file stored as an operating system file to provide additional
flexibility for managing Oracle databases. This file is encrypted and
contains userids and passwords that can be used to perform
administrative tasks, such as starting and stopping the instance.
Password files are typically used to implement remote access security
in addition to access security by operating system, which is usually
used locally (i.e., on the database server). For example, on a Unix
system, any user in the DBA group can start up or shut down
Oracle�the operating system group gives them the authority.
However, the database server operating-system authentication always
has priority over a password-file authentication and cannot be used
to force the entry of a password if operating system authentication
is enabled. Validating a password against the value stored in the
database for a user is not possible when the database is not open.
The password file forces a user to authenticate herself with a
password in order to start up the database.
Figure 2-8 illustrates the memory structures and background
processes, which are discussed in the following sections.
Additional background processes may exist when you use certain other
features of the database: for example, shared servers (formerly the
Multi-Threaded Server or MTS prior to Oracle9i),
or job queues and replication. For now, we'll just
describe the basic pieces of an Oracle instance and leave the
optional pieces for later in the book. We'll discuss
the shared server processes in Chapter 3, and replication processes
in Chapter 10.
2.3.1 Memory Structures for an Instance
As shown in Figure 2-8, the
System
Global Area is actually composed of three main areas: the database
buffer cache, the shared pool, and the redo log buffer.
Another type of memory pool, the large pool (not shown in Figure 2-8), was introduced in Oracle8. This optional area of the SGA
is used for buffering I/O for various server processes, including
those used for backup and recovery. The area is also used to store
session memory for the shared server and when using the XA protocol
for distributed transactions, as discussed in Chapter 12.
This alternate pool exists to reduce the demand on the shared pool
for certain large memory allocations. The initialization parameter
used to configure the large pool is LARGE_POOL_SIZE.
The following sections describe these areas of the SGA. For a more
detailed discussion of performance issues for these areas, see
"How Oracle Uses the System Global
Area" in Chapter 6. Note that in Oracle Database
10g, the initialization parameters that affect the size of the SGA
are now dynamic.
2.3.1.1 Database buffer cache
The database buffer cache caches blocks of
data retrieved from the database. This buffer between the
users' requests and the actual datafiles improves
the performance of the Oracle database. If a piece of data can be
found in the buffer cache, you can retrieve it from memory without
the overhead of having to go to disk. Oracle manages the cache using
a least
recently used (LRU) algorithm. If a user requests data
that has been recently used, the data is more likely to be in the
database buffer cache; data in the cache can be delivered immediately
without a disk read operation being executed.
When a user wants to read a block that is not in the cache, the block
must be read and loaded into the cache. When a user makes changes to
a block, those changes are made to the block in the cache. At some
later time, those changes will be written to the datafile in which
the block resides. This avoids making users wait while Oracle writes
their changed blocks to disk.
This notion of waiting to perform I/O until absolutely necessary is
common throughout Oracle. Disks are the slowest
component of a computer system, so the less I/O performed, the faster
the system runs. By deferring noncritical I/O operations instead of
performing them immediately, an Oracle database can deliver better
performance.
Oracle7 had one pool of buffers for database blocks.
Oracle8 introduced multiple buffer
pools. There are three pools available in Oracle8 and beyond:
- DEFAULT
The
standard Oracle database buffer cache. All objects use this cache
unless otherwise indicated.
- KEEP
For
frequently used objects you wish to cache.
- RECYCLE
For
objects you're less likely to access again.
Both the KEEP and RECYCLE buffer pools remove their objects from
consideration by the LRU algorithm.
You can mark a table or index for caching in a specific buffer pool.
This helps to keep more desirable objects in the cache and avoids the
"churn" of all objects fighting for
space in one central cache. Of course, to use these features properly
you must be aware of the access patterns for the various objects used
by your application.
Oracle Database 10g
simplifes management of buffer cache size by introducing a new
dynamic parameter, DB_CACHE_SIZE. This parameter replaces
the DB_BLOCK_BUFFERS parameter present in previous Oracle releases.
2.3.1.2 Shared pool
The shared pool
caches various constructs that can be shared among users. For
example, SQL statements issued by users are cached so they can be
reused if the same statement is submitted again. Another example is
stored procedures, or pieces of code stored and executed within the
database. These are loaded into the shared pool for execution and
then cached, again using an LRU algorithm. The shared pool is also
used for caching information from the Oracle data dictionary, which
is the metadata that describes the structure and content of the
database itself. Note that prior to Oracle Database 10g,
"out of memory" errors were
possible if the shared pool was undersized. Oracle Database 10g
provides automatic shared memory tuning.
2.3.1.3 Redo log buffer
The redo log
buffer caches redo information until it is written to the physical
redo log files stored on a disk. This buffer also improves
performance. Oracle caches the redo until it can be written to a disk
at a more optimal time, which avoids the overhead of constantly
writing the redo logs to disk.
2.3.2 Background Processes for an Instance
The background processes shown in
Figure 2-8 are:
- Database Writer (DBWR)
The Database Writer process writes database
blocks from the database buffer cache in the SGA to the datafiles on
disk. An Oracle instance can have up to 10 DBWR processes, from DBW0
to DBW9, to handle the I/O load to multiple datafiles. Most instances
run one DBWR. DBWR writes blocks out of the cache for two main
reasons:
If Oracle needs to perform a checkpoint (i.e., to update the blocks
of the datafiles so that they "catch
up" to the redo logs). Oracle writes the redo for a
transaction when it's committed, and later writes
the actual blocks. Periodically, Oracle performs a checkpoint to
bring the datafile contents in line with the redo that was written
out for the committed transactions. If Oracle needs to read blocks requested by users into the cache and
there is no free space in the buffer cache. The blocks written out
are the least recently used blocks. Writing blocks in this order
minimizes the performance impact of losing them from the buffer
cache.
- Log Writer (LGWR)
The Log Writer process writes the redo
information from the log buffer in the SGA to all copies of the
current redo log file on disk. As transactions proceed, the
associated redo information is stored in the redo log buffer in the
SGA. When a transaction is committed, Oracle makes the redo
information permanent by invoking the Log Writer to write it to disk.
- System Monitor (SMON)
The System Monitor process maintains overall
health and safety for an Oracle instance. SMON performs crash
recovery when the instance is started after a failure and coordinates
and performs recovery for a failed instance when you have more than
one instance accessing the same database, as with Oracle Parallel
Server/Real Application Clusters. SMON also cleans up adjacent pieces
of free space in the datafiles by merging them into one piece and
gets rid of space used for sorting rows when that space is no longer
needed.
- Process Monitor (PMON)
The Process Monitor process watches over the
user processes that access the database. If a user process terminates
abnormally, PMON is responsible for cleaning up any of the resources
left behind (such as memory) and for releasing any locks held by the
failed process.
- Archiver (ARC)
The Archiver process reads the redo log
files once Oracle has filled them and writes a copy of the used redo
log files to the specified archive log destination(s).
Since Oracle8i, an
Oracle instance can have up to 10 processes, numbered as described
for DBWR above. LGWR will start additional Archivers as needed, based
on the load, up to the limit specified by the initialization
parameter LOG_ARCHIVE_MAX_PROCESSES.
- Checkpoint (CKPT)
The Checkpoint process works with DBWR to
perform checkpoints. CKPT updates the control file and database file
headers to update the checkpoint data when the checkpoint is
complete.
- Recover (RECO)
The Recover process automatically cleans
up failed or suspended distributed transactions (discussed in Chapter 10).
With all this talk about
processes, you may be wondering whether
Oracle actually uses threads or processes in the underlying operating
system to implement these services.
For simplicity, throughout this book we use the term
process generically to indicate a function that
Oracle performs, such as DBWR or LGWR. Oracle on Windows uses one
operating system process per instance; thus each
"Oracle process" is actually a
thread within the one Oracle process. Oracle on
Unix uses a process-based architecture. All of the
"processes" are actual operating
system processes, not threads. Thus, on Unix DBWR, LGWR, and so on
are specific operating system processes, while on Windows they are
threads within a single process.
There are some exceptions, however. For instance, the shared server
uses real threads on Windows and simulated threads on Unix.
|
|
No comments:
Post a Comment