The Oracle
DBMS Architecture:
BY DANIEL D. KITAY
As more and more database
and system administrators
support multiple DBMSes,
it’s important to understand
the architecture of the system
and its components.
This article introduces
the reader to the Oracle DBMS.
TECHNICAL SUPPORT February ‘97
A Technical Introduction
TODAY’S database and system
administrators must sup-
port more and more Database Management
Systems (DBMSes) from different vendors
running on various hardware and operating
system platforms. One of these DBMSes is
the Oracle 7 server.
To effectively administer Oracle 7 servers
and the databases accessed, it’s important
to understand the Oracle 7 server archi-
tecture. This article examines the Oracle 7
server architecture and its major components.
It is intended to benefit new Oracle program-
mers, DBAs, system administrators and
their managers.
Although it is impossible to describe
all of the features and components of the
Oracle 7 server in just one article, the fol-
lowing essential topics are discussed:
◆ instance and database startup;
◆ instance and application processes;
◆ server memory structures;
◆ server and database files; and
◆ performance monitoring and tuning.
INSTANCE AND DATABASE STARTUP
As depicted in Figure 1, an Oracle server
instance is the combination of server back-
ground processes and memory structures
that allow database data to be stored,
managed and accessed by users. During
Oracle server startup, an init.ora configu-
ration file (similar to DB2’s DSNZPARM)
is read in and a number of background
processes are created that perform specific
database and server functions. The process
of starting an instance includes the allocation
of several memory structures, including the
System Global Area (SGA) and Program
Global Area (PGA), both of which are
discussed later.
Typically, during server startup a data-
base is immediately mounted and opened
to allow user and application access.
Mounting a database is the process of asso-
ciating a database with the started Oracle
server’s background processes and allocated
memory structures. Although DB2 supports
multiple databases accessible from a single
subsystem, the Oracle 7 server supports
access only to a single database at a time.
When a database is mounted, the instance
finds and opens its control files. The control
© 1996 Candle Corporation. Reprinted with permission. All rights reserved. International copyright secured.
files specify the names of the database’s
data files and redo log files. A database can
be mounted in either exclusive or parallel
mode. Parallel mode allows an Oracle
Parallel Server (OPS) environment to exist
by allowing multiple Oracle servers across
multiple machines to mount the same
shared database.
Opening a mounted database is the
process of making the database available
for normal database operations. When an
instance opens a database, one or more
rollback segments are acquired so that the
instance can handle rollback information
produced by subsequent transaction exe-
cutions. At this point, any valid user can
connect to the database and access or
change information. When the database is
opened, the online data and redo log files
are also opened. An instance can also be
started in (or later, dynamically altered to
be in) restricted mode so that when the
database is open, connections are limited
only to those whose user accounts have
been granted the RESTRICTED SESSION
system privilege.
http://www.naspa.net

Figure 1: Oracle 7 Architecture: Processes, Memory and Files
SMON
Systems Global Area (SGA)
Database
Buffer
Cache
Shared
Server
User
Processes
Processes
(Snnn)
(access via MTS)
Dnnn User Process
A database is sometimes left unmounted,
or mounted and unopened, during startup to
allow execution of administrative functions
that require the database’s data to be
unavailable to users.
INSTANCE AND APPLICATION PROCESSES
An Oracle DBMS comprises two types
of processes: user and Oracle system. A
user or client process is created to execute
the program code of an application. It also
manages the communication with the
Oracle server processes. Oracle system
processes are called by other users or
Oracle processes to perform functions on
behalf of the invoking process. Oracle sys-
tem processes are divided into two types:
server processes and background processes.
Server processes exist to service requests
from connected user processes. A server
process receives SQL statement requests,
checks the shared pool within the SGA for
the parsed form of the SQL statement (if it
does not exist within the shared pool, it is
read in and parsed), checks user access
privilege, retrieves data from the actual data
file or data that is already cached in the
instance’s SGA, and makes the data avail-
able to the requesting application.
In a dedicated server configuration
(sometimes called two-task Oracle), each
server process handles requests for a single
user process. In this type of system, the
application process and the Oracle server
process frequently execute on different
machines. Even when the user is not actively
making a database request, the dedicated
http://www.naspa.net
S Y S T E M S
process. The shared server process per-
RECO
forms the same function as a dedicated
PMON
server process, but after servicing each
SQL request it is free to service requests
LCKn
from a different user process. Configuration
(Oracle Parallel values control the initial and maximum
Server)
Shared Pool number of shared servers allowed active
Shared SQL
Redo Log
Areas or at one time. Request and response queues
Buffer
Library Cache
Dictionary
Archive Storage are used by the dispatchers and shared
Cache servers to communicate SQL requests and
CKPT LGWR
to return data results.
At startup time, Oracle creates a number
ARCH
DBWR of system background processes for each
Dedicated
Server Control Files instance to perform system functions:
Processes Database Redo Log
Files Files
◆ The System Monitor (SMON) performs
instance recovery during startup, cleans
up temporary segments that are no longer
in use, recovers dead transactions skipped
during crash and instance recovery
because of file-read or offline errors, and
server process still exists. These dedicated coalesces small chunks of contiguous
connections are always required when free space into larger blocks of contigu-
executing certain Oracle administration ous space for easier allocation by Oracle.
functions, such as database startup, shut-
down and recovery. ◆ The Process Monitor (PMON) performs
In a Multi-Threaded Server (MTS) recovery when a user process fails.
configuration, as shown in Figure 2, many PMON cleans up the cache and frees
user processes can be serviced by a smaller resources that the process was using.
number of shared server processes. This PMON also restarts failed dispatcher
helps reduce process memory utilization and shared server processes.
and process management overhead. An
MTS configuration uses a SQL*Net net- ◆ The Database Writer (DBWR) writes
work listener process to connect user modified (dirty) data blocks from the
processes to dispatchers, which route client database cache to data files on disk
requests to the next available shared server using a least recently used algorithm.
Figure 2: Oracle Multi-Threaded Server Architecture
User processes
and
application code
Client Workstations
Database Server
Listener
Dispatcher processes (Dnnn)
TCP/IP
xxxxxxx
yyyyyyy
Shared
Server
Processes
(Snnn)
Request
Queue Response Queue
(common to all (one per dispatcher)
dispatchers)
System Global Area
February ‘97 TECHNICAL SUPPORT
S Y S T E M S
Whenever possible, DBWR writes dirty
buffers to disk using a multi-block write
mechanism. DBWR manages the buffer
cache so that user processes can always
find free buffers. The DBWR process
is signaled to write dirty buffers to disk
under the following conditions:
• when the dirty list reaches a threshold
length defined by the init.ora parameter
DB_BLOCK_WRITE_BATCH;
• when a free buffer has not been
found after n buffers have been
scanned (where n is defined by
DB_BLOCK_MAX_SCAN_CNT
in init.ora);
• when a timeout occurs (every
three seconds);
• when a checkpoint occurs; and
• when the Log Writer (LGWR)
signals DBWR.
◆ The LGWR is triggered during several
internal events (commit, checkpoint,
and log write timeout), as well as when
the redo log buffer is one-third full.
This process writes the redo log buffer
in memory to the redo log file on disk.
During each Checkpoint (CKPT), the
LGWR updates file headers if a CKPT
process is not configured to perform
this function.
◆ The optional CKPT updates the headers
of all data files during checkpoint
processing. If the init.ora CHECK-
POINT_PROCESS parameter is
enabled, this process can improve
system performance by freeing the
LGWR to concentrate on the redo
log buffer. The CKPT process does
not write data blocks to disk; this is
performed by the DBWR.
◆ The Recoverer (RECO) is started when
distributed transactions are permitted
and the init.ora parameter DISTRIB-
UTED_TRANSACTIONS is greater
than zero. The Oracle distributed
option uses the RECO process to
automatically resolve distributed
transaction failures.
◆ The Archiver (ARCH) copies online
redo log files, once they become full,
to a specified storage device or location.
ARCH is present only when the data-
base is started in ARCHIVELOG mode
and automatic archiving is enabled.
TECHNICAL SUPPORT February ‘97
An Oracle DBMS comprises
two types of processes:
user and Oracle system.
A user or client process
is created to execute the program
code of an application.
It also manages the communication
with the Oracle server processes.
Oracle system processes
are called by other users
or Oracle processes
to perform functions on behalf
of the invoking process.
◆ Lock (LCKn) processes are used
in conjunction with the Parallel Server
option. Up to 10 LCK processes (LCK0
through LCK9) are used to control
inter-instance locking.
◆ Dispatcher (Dnnn) processes, used with
the MTS configuration, allow user
processes to share a limited number
of shared server processes. At least
one dispatcher process must be created
for each network protocol used to
communicate with Oracle.
◆ Parallel Query server processes are used
with the Parallel Query option in Oracle
7.1 or higher. With this option, a query
coordinator (QC) intercepts queries,
decides if they should be split into
multiple smaller queries, and sends
them to the pool of available query
servers for processing. Query servers
are also used for parallel index creation
and data loads. The number of query
servers automatically increases or
decreases (within the upper and lower
limits set by the administrator) to
accommodate changing workload levels.
◆ Snapshot (SNPn) processes are used
with the Oracle distributed option to
automatically refresh table snapshots.
These processes “wake-up” periodically
when snapshots are scheduled to be
automatically refreshed.
SERVER MEMORY STRUCTURES
To operate, each Oracle instance allocates
a number of cache areas. As shown in
Figure 1, the major memory areas are the
SGA, PGA and sort areas.
The SGA is a single shared memory
area consisting of three main components:
Database Buffer cache, Shared Pool and
Redo Log buffer. The size of the SGA
is based on various init.ora parameter
values including: DB_BLOCK_SIZE,
DB_BLOCK_BUFFERS, LOG_BUFFER,
and SHARED_POOL_SIZE.
The Database Buffer cache holds the
most recently used data from files on
disk. It is similar to using a single DB2
Buffer Pool (BP), but without the ability
to dynamically alter its size. Database
Buffer cache size is determined at Oracle
startup based on the DB_BLOCK_BUF-
FERS parameter. Each block size is
usually between 2KB and 32KB (in
multiples of 2KB), as determined by
DB_BLOCK_SIZE.
The Shared Pool is similar to DB2’s
Environmental Descriptor Manager pool,
which contains runtime definitions for SQL
statements and other dictionary information.
The Shared Pool contains cache areas for
parsing and storing SQL and PL/SQL state-
ments (Shared SQL Area); a Data Dictionary
cache (row cache) which contains database
reference information, similar to DB2’s
dictionary database; and, in an MTS configu-
ration, private SQL areas containing binding
information and run-time buffers. The
SHARED_POOL_SIZE parameter defines
the size of the Shared Pool.
The Redo Log buffer is an area of the
SGA that Oracle uses to record database
related changes caused by SQL INSERT,
UPDATE, DELETE, CREATE, ALTER, or
DROP, and to recreate data or objects during
recovery of an executing transaction. It is a
circular buffer that contains redo entries
containing the information necessary to
reconstruct or redo changes made to the
database. Redo entries are later copied to
the active redo log file on disk. Oracle’s
logging functions are very similar to DB2
log buffer and online log files. Redo Log
buffer size is determined by the LOG_BUF-
FER parameter.
Oracle also uses rollback segments.
These memory areas store pre-update
images that can be used to rollback transac-
tion updates and allow access to data as it is
being updated (dirty reads).
http://www.naspa.net

When the MTS is configured, request
and response queues and some contents of
the PGA are stored within the SGA. Other
information that needs to be communicated
between processes, such as locking infor-
mation, is also stored within the SGA. A
fixed SGA area stores information about
the state of the database and instance for
access by background processes.
The PGA is memory that contains data
and control information for an Oracle
instance or application process. Each
process has its own PGA; its contents vary
depending on whether an MTS configuration
is used by a user or application to connect
to the Oracle instance. Each process PGA
always contains stack space, which is
memory used to hold a session’s variables,
arrays and other information. A PGA
without an MTS connection requires addi-
tional memory for the user’s session, such
as private SQL areas. If the connection uses
an MTS, the extra memory is allocated to
the SGA instead of the PGA. Several
initialization parameters affect the size
of a PGA, including OPEN_LINKS,
DB_FILES and LOG_FILES.
On top of physical SGA and PGA
memory, some logical memory structures
are created. These structures may be shared
or private and differ as to when they are
allocated and deallocated. Logical memory
structures include: User Global Area (UGA),
Call Global Area (CGA), Shared Context
Areas or Cursors, Cursor Ephemeral Frame,
Cursor Work Heap, Cursor Persistent Frame,
and connection memory (HGA). For more
information on these areas, refer to the article
UGA and More Undocumented Features in
the bibliography.
Finally, sorting requires sort space in
memory. A sort area exists in the memory
of an Oracle user process that requests a
sort. A sort area dynamically grows to
accommodate the amount of data to be
sorted, within the limits of the
SORT_AREA_SIZE value. If Oracle does
not need to reference the sort area, it may
dynamically reduce its size as determined
by the SORT_AREA_RETAINED_SIZE
parameter. When needed, Oracle uses tem-
porary segments on disk to contain sort
work areas. These temporary segments are
dynamically created and deleted on an “as
needed” basis. In Oracle 7.3, permanent
segments can be created to contain sort
work areas, similar to the permanently
allocated sort work tables in DB2. This
http://www.naspa.net
eliminates the overhead associated with
frequently creating and deleting temporary
sort segments.
In Oracle 7.3,
permanent segments can be created
to contain sort work areas,
similar to the permanently
allocated sort work tables in DB2.
SERVER AND DATABASE FILES
An Oracle instance uses a number of dif-
ferent physical and logical structures to
operate. Some of the physical structures
used by an Oracle instance are shown in
Figure 1:
◆ Oracle database files contain database
information, including both system
and application data. System data
files contain the contents of the
SYSTEM tablespace, including
the data dictionary and the names
and locations of all objects within
the database. Application data files
hold user data that is accessed by
SQL statements.
◆ Oracle parameter file, init.ora, contains
startup parameters to customize the
Oracle instance’s execution environment.
◆ Control files are used to record the
names of the database’s data files
and redo log files as well as other
status and configuration information.
◆ Online and Archived Redo log files
record changes made to data and
ensure that no data is lost in the event
of an instance failure. An online redo
log consists of two or more pre-allocated
files that store all changes made to the
database as they occur. Archived
(offline) redo logs consist of archived
online redo log files that become full.
The archived redo log is optional based
on a database’s archiving mode.
◆ Database backup files can be created
to support the restoration of damaged
data files or control files.
S Y S T E M S
Figure 3: Oracle Database Logical
and Physical Structures
Database
Tablespace
Data Files
Segment
(index)
(temporary)
Extents
Blocks
◆ Process trace files can exist for each
server and background process. When
a process detects an internal error it
dumps error information to its trace
file. Trace files can also contain SQL
tuning information when the initial-
ization parameter SQL_TRACE is set
TRUE (although this global setting is
expensive) or when a session enables
trace logging by using the ALTER
SESSION SET SQL_TRACE =
TRUE command.
◆ An instance’s ALERT file contains
a chronological log of messages
and errors generated by an instance.
◆ One or more configuration files
on each client and server define
SQL*NET communications and
enable client/server connections.
As shown in Figure 3, an Oracle database
contains several logical structures defined
on top of a physical data file’s user or system
data. Within an Oracle database, the logical
structures from the highest to lowest level
include: tablespaces, segments, extents and
data blocks.
February ‘97 TECHNICAL SUPPORT
S Y S T E M S
A database is divided into one or more
logical storage units called tablespaces. A
database administrator can create new
tablespaces, add data files for tablespaces,
set and alter default segment storage settings
for segments created in a tablespace and
drop tablespaces. Every database contains a
tablespace named SYSTEM that is auto-
matically built during database creation.
This tablespace contains the data dictionary
tables for the entire database. It is similar to
the DB2 catalog and dictionary databases.
To add more space to a database, data files
can be added to one of its existing table-
spaces up to the database limit of the total
number of files allowed.
The next level of logical structures are
segments. A segment is a set of extents
stored in the same tablespace that have been
allocated for a specific type of data structure.
For example, each table’s data is stored in
its own data segment, while each index’s
data is stored in its own index segment.
Both segment types can reside in the same
tablespace and physical files, which is very
different from DB2’s implementation of
separate table- and indexspaces. Segment
extents can span one or more files assigned
to a tablespace. When the existing extents
for a segment are full, Oracle allocates
another extent for that segment. Since
extents are allocated as needed, segment
extents may be non-contiguous. The main
segment types are:
◆ one data segment per table, snapshot,
or snapshot log defined;
◆ one index segment per index defined;
◆ one or more rollback segments
for recording transaction change
activity; and
◆ one or more temporary segments
to contain sort and other types
of work areas.
The next level of logical database space
is called an extent. An extent is a specific
number of contiguous data blocks that is
allocated for storing a specific type of
information. A single extent cannot span a
physical file.
A data block is the smallest unit of I/O
used by an instance. A data block corre-
sponds to a block of physical bytes on
disk, equal to the Oracle data block size.
This block size can differ from the stan-
dard I/O block size of the operating
system that executes Oracle; it is usually
TECHNICAL SUPPORT February ‘97
either 2KB or 4KB. Each data block
contains a header, row directory, row data
and free space.
Oracle 7 has many
configuration options
and optional features
that must be
carefully implemented
and tuned for you to optimize
your system
and application performance.
PERFORMANCE MONITORING AND TUNING
The Oracle server product includes a
number of built-in and add-on tools and
mechanisms for monitoring the perfor-
mance of an Oracle instance and tuning
performance. These mechanisms are:
◆ more than 30 memory resident tables
(X$ tables) and the views on them
(V$ tables), providing a wealth of
performance and configuration infor-
mation to users and third-party
performance monitors, such as
Candle’s OMEGAMON Monitoring
Agents for Oracle.
◆ SQL*DBA monitor facilities
(or the more graphical Oracle 7.3
replacement, Server Manager) to
display the contents of dynamic
performance tables.
◆ Oracle scripts for performance
monitoring, including UTLBSTAT,
UTLESTAT, and UTLLOCKT.SQL
for reviewing locking conflicts.
◆ an ANALYZE SQL statement that tells
Oracle to collect and store tablespace
related statistics, similar to DB2’s
RUNSTATS utility.
◆ a SQL EXPLAIN PLAN facility,
similar to DB2’s, that allows
you to review access path choices
made by Oracle’s cost- and
rule-based optimizer.
◆ a SQL statement tracing facility
(SQL_TRACE) that can be
enabled globally for all SQL
statements (although not
recommended because of high
overhead) or at the individual
session level. Trace records are
written to a file that can be read
by a translation and reporting
utility called TKPROF.
◆ Oracle 7.3 provides more extensive
tracing and instrumentation facilities
that can be controlled and reported
on by an additional product called
Oracle Trace.
ORACLE 7: THE POWER AND COMPLEXITY
This article described the major
components of the Oracle 7 server to
show both the power and the complexity
of this database management system.
It has many configuration options and
optional features that must be carefully
implemented and tuned for you to
optimize your system and application
performance. ts
BIBLIOGRAPHY
Oracle 7 Server Concepts,
Part No. 6693-70-1292
Oracle 7.2 Parallel Server,
Part No. A19487-2
UGA and More Undocumented Features,
Tony Jambu, Select Journal, July 1995.
Daniel D. Kitay is R&D manager at Candle
Corporation’s Westlake, Calif., R&D office.
He specializes in designing and implementing
applications to manage the performance and
availability of distributed systems and applications.
For the past 13 years Daniel has worked with IMS,
VTAM, DB2 for MVS, and more recently, Oracle,
Sybase, Lotus Notes and SAP. He can be reached
at dan_kitay@candle.com.
©1997 Technical Enterprises, Inc. Reprinted
with permission of Technical Support maga-
zine. For subscription information, email
mbrship@naspa.net or call 414-768-8000,
Ext. 116.
http://www.naspa.net