Objectives

This lesson provides a detailed overview of the Oracle Database architecture. You learn about the
physical and logical structures and about various components.

Oracle Database 11g: Administration Workshop I 1 - 2

Oracle Database
A database is a collection of data treated as a unit. The purpose of a database is to store and retrieve
related information.
Oracle Database reliably manages a large amount of data in a multiuser environment so that many
users can concurrently access the same data. This is accomplished while delivering high
performance. At the same time, it prevents unauthorized access and provides efficient solutions for
failure recovery.

Oracle Database 11g: Administration Workshop I 1 - 3

Connecting to a Server
A database user can connect to an Oracle server in one of three ways:
• The user logs on to the operating system running the Oracle instance and starts an application or
tool that accesses the database on that system. The communication pathway is established using
the interprocess communication mechanisms available on the host operating system.
• The user starts the application or tool on a local computer and connects over a network to the
computer running the Oracle database. In this configuration (called client/server), network
software is used to communicate between the user and the back-end server.
The client/server architecture database system has two parts: a front end (client) and a back end
(server) connected through a network. Network software is used to communicate between the
user and the Oracle server.
- The client is a database application that initiates a request for an operation to be performed
on the database server. It requests, processes, and presents data managed by the server. The
client workstation can be optimized for its job. For example, the client might not need large
disk capacity, or it might benefit from graphic capabilities. Often, the client runs on a
different computer than the database server. Many clients can simultaneously run against
one server.

Oracle Database 11g: Administration Workshop I 1 - 4

Oracle Database Architecture
An Oracle database consists of an instance and its associated databases. The instance consists of
memory structures and background processes. Every time an instance is started, a shared memory
area called the System Global Area (SGA) is allocated and the background processes are started.
The database consists of both physical structures and logical structures. Because the physical and
logical structures are separate, the physical storage of data can be managed without affecting access
to logical storage structures.

Oracle Database 11g: Administration Workshop I 1 - 6

Connecting to the Database
Connections and sessions are closely related to user processes but are very different in meaning.
A connection is a communication pathway between a user process and an Oracle Database instance.
A communication pathway is established using available interprocess communication mechanisms
(on a computer that runs both the user process and Oracle Database) or network software (when
different computers run the database application and Oracle Database, and communicate through a
network).
A session represents the state of a current user login to the database instance. For example, when a
user starts SQL*Plus, the user must provide a valid username and password, and then a session is
established for that user. A session lasts from the time a user connects until the user disconnects or
exits the database application.
In the case of a dedicated connection, the session is serviced by a permanent dedicated process. The
session is serviced by an available server process selected from a pool, either by the middle tier or by
Oracle shared server architecture.
Multiple sessions can be created and exist concurrently for a single Oracle database user using the
same username. For example, a user with the username/password of HR/HR can connect to the same
Oracle Database instance several times.

Oracle Database 11g: Administration Workshop I 1 - 7

Interacting with an Oracle Database
The following example describes Oracle database operations at the most basic level. It illustrates an
Oracle database configuration in which the user and associated server process are on separate
computers, connected through a network.
1. An instance has started on a node where Oracle Database is installed, often called the host or
database server.
2. A user starts an application spawning a user process. The application attempts to establish a
connection to the server. (The connection may be local, client/server, or a three-tier connection
from a middle tier.)
3. The server runs a listener that has the appropriate Oracle Net Services handler. The server
detects the connection request from the application and creates a dedicated server process on
behalf of the user process.
4. The user runs a DML-type SQL statement and commits the transaction. For example, the user
changes the address of a customer in a table and commits the change.
5. The server process receives the statement and checks the shared pool (an SGA component) for
any shared SQL area that contains a similar SQL statement. If a shared SQL area is found, the
server process checks the user’s access privileges to the requested data, and the existing shared
SQL area is used to process the statement. If a shared SQL area is not found, a new shared SQL
area is allocated for the statement so that it can be parsed and processed.

Oracle Database 11g: Administration Workshop I 1 - 8

Oracle Database Server Structures
After starting an instance, the Oracle software associates the instance with a specific database. This is
called mounting the database. The database is then ready to be opened, which makes it accessible to
authorized users. Multiple instances can execute concurrently on the same computer, each accessing
its own physical database.
You can look at the Oracle Database architecture as various interrelated structural components.
An Oracle instance uses memory structures and processes to manage and access the database. All
memory structures exist in the main memory of the computers that constitute the database server.
Processes are jobs that work in the memory of these computers. A process is defined as a “thread of
control” or a mechanism in an operating system that can run a series of steps.

Oracle Database 11g: Administration Workshop I 1 - 10

Oracle Database Memory Structures
Oracle Database creates and uses memory structures for various purposes. For example, memory
stores program code being run, data that is shared among users, and private data areas for each
connected user.
Two basic memory structures are associated with an instance:
• System Global Area (SGA): Group of shared memory structures, known as SGA components,
that contain data and control information for one Oracle Database instance. The SGA is shared
by all server and background processes. Examples of data stored in the SGA include cached data
blocks and shared SQL areas.
• Program Global Areas (PGA): Memory regions that contain data and control information for a
server or background process. A PGA is nonshared memory created by Oracle Database when a
server or background process is started. Access to the PGA is exclusive to the server process.
Each server process and background process has its own PGA.

Oracle Database 11g: Administration Workshop I 1 - 11

Database Buffer Cache
The database buffer cache is the portion of the SGA that holds copies of data blocks that are read
from data files. All users who are concurrently connected to the instance share access to the database
buffer cache.
The first time an Oracle Database user process requires a particular piece of data, it searches for the
data in the database buffer cache. If the process finds the data already in the cache (a cache hit), it
can read the data directly from memory. If the process cannot find the data in the cache (a cache
miss), it must copy the data block from a data file on disk into a buffer in the cache before accessing
the data. Accessing data through a cache hit is faster than data access through a cache miss.
The buffers in the cache are managed by a complex algorithm that uses a combination of least
recently used (LRU) lists and touch count.

Oracle Database 11g: Administration Workshop I 1 - 13

Redo Log Buffer
The redo log buffer is a circular buffer in the SGA that holds information about changes made to the
database. This information is stored in redo entries. Redo entries contain the information necessary to
reconstruct (or redo) changes that are made to the database by DML, DDL, or internal operations.
Redo entries are used for database recovery if necessary.
Redo entries are copied by Oracle Database processes from the user’s memory space to the redo log
buffer in the SGA. The redo entries take up continuous, sequential space in the buffer. The LGWR
background process writes the redo log buffer to the active redo log file (or group of files) on disk.

Oracle Database 11g: Administration Workshop I 1 - 14

Shared Pool
The shared pool portion of the SGA contains the library cache, the data dictionary cache, the SQL
query result cache, the PL/SQL function result cache, buffers for parallel execution messages, and
control structures.
The data dictionary is a collection of database tables and views containing reference information
about the database, its structures, and its users. Oracle Database accesses the data dictionary
frequently during SQL statement parsing. This access is essential to the continuing operation of
Oracle Database.
The data dictionary is accessed so often by Oracle Database that two special locations in memory are
designated to hold dictionary data. One area is called the data dictionary cache, also known as the
row cache because it holds data as rows instead of buffers (which hold entire blocks of data). The
other area in memory to hold dictionary data is the library cache. All Oracle Database user processes
share these two caches for access to data dictionary information.
Oracle Database represents each SQL statement that it runs with a shared SQL area (as well as a
private SQL area kept in the PGA). Oracle Database recognizes when two users are executing the
same SQL statement and reuses the shared SQL area for those users.

Oracle Database 11g: Administration Workshop I 1 - 15

Allocation and Reuse of Memory in the Shared Pool
In general, any item (shared SQL area or dictionary row) in the shared pool remains until it is flushed
according to a modified LRU (least recently used) algorithm. The memory for items that are not
being used regularly is freed if space is required for new items that must be given some space in the
shared pool. A modified LRU algorithm allows shared pool items that are used by many sessions to
remain in memory as long as they are useful, even if the process that originally created the item
terminates. As a result, the overhead and processing of SQL statements associated with a multiuser
Oracle Database system are minimized.
When a SQL statement is submitted to Oracle Database for execution, the following memory
allocation steps are automatically performed:
1. Oracle Database checks the shared pool to see if a shared SQL area already exists for an
identical statement. If so, that shared SQL area is used for the execution of the subsequent new
instances of the statement. If there is no shared SQL area for a statement, Oracle Database
allocates a new shared SQL area in the shared pool. In either case, the user’s private SQL area is
associated with the shared SQL area that contains the statement.

Oracle Database 11g: Administration Workshop I 1 - 17

Large Pool
The database administrator can configure an optional memory area called the large pool to provide
large memory allocations for:
Session memory for the shared server and the Oracle XA interface (used where transactions interact
with more than one database):
• I/O server processes
• Oracle Database backup and restore operations
By allocating session memory from the large pool for shared server, Oracle XA, or parallel query
buffers, Oracle Database can use the shared pool primarily for caching shared SQL and avoid the
performance overhead that is caused by shrinking the shared SQL cache.
In addition, the memory for Oracle Database backup and restore operations, for I/O server processes,
and for parallel buffers is allocated in buffers of a few hundred kilobytes. The large pool is better able
to satisfy such large memory requests than the shared pool.
The large pool does not have an LRU list. It is different from reserved space in the shared pool,
which uses the same LRU list as other memory allocated from the shared pool.

Oracle Database 11g: Administration Workshop I 1 - 19

Java Pool and Streams Pool
Java pool memory is used in server memory for all session-specific Java code and data in the JVM.
Java pool memory is used in different ways, depending on the mode in which Oracle Database is
running.
The Java Pool Advisor statistics provide information about library cache memory used for Java and
predict how changes in the size of the Java pool can affect the parse rate. The Java Pool Advisor is
internally turned on when statistics_level is set to TYPICAL or higher. These statistics reset
when the advisor is turned off.
The Streams pool is used exclusively by Oracle Streams. The Streams pool stores buffered queue
messages, and it provides memory for Oracle Streams capture processes and apply processes.
Unless you specifically configure it, the size of the Streams pool starts at zero. The pool size grows
dynamically as needed when Oracle Streams is used.
Note: A detailed discussion of Java programming and Oracle Streams is beyond the scope of this
class

Oracle Database 11g: Administration Workshop I 1 - 20

Process Architecture
The processes in an Oracle Database system can be divided into two major groups:
• User processes that run the application or Oracle tool code
• Oracle Database processes that run the Oracle database server code (including server processes
and background processes)
When a user runs an application program or an Oracle tool such as SQL*Plus, Oracle Database
creates a user process to run the user’s application. Oracle Database also creates a server process to
execute the commands issued by the user process. In addition, the Oracle server also has a set of
background processes for an instance that interact with each other and with the operating system to
manage the memory structures, asynchronously perform I/O to write data to disk, and perform other
required tasks.
The process structure varies for different Oracle Database configurations, depending on the operating
system and the choice of Oracle Database options. The code for connected users can be configured as
a dedicated server or a shared server.
• Dedicated server: For each user, the database application is run by a user process that is served
by a dedicated server process that executes Oracle database server code.
• Shared server: Eliminates the need for a dedicated server process for each connection. A
dispatcher directs multiple incoming network session requests to a pool of shared server
processes. A shared server process serves any client request.

Oracle Database 11g: Administration Workshop I 1 - 21

Process Structures
Server Processes
Oracle Database creates server processes to handle the requests of user processes connected to the
instance. In some situations, when the application and Oracle Database operate on the same
computer, it is possible to combine the user process and corresponding server process into a single
process to reduce system overhead. However, when the application and Oracle Database operate on
different computers, a user process always communicates with Oracle Database through a separate
server process.
Server processes created on behalf of each user’s application can perform one or more of the
following:
• Parse and run SQL statements issued through the application
• Read necessary data blocks from data files on disk into the shared database buffers of the SGA
(if the blocks are not already present in the SGA)
• Return results in such a way that the application can process the information
Background Processes
To maximize performance and accommodate many users, a multiprocess Oracle Database system
uses some additional Oracle Database processes called background processes. An Oracle Database
instance can have many background processes.

Oracle Database 11g: Administration Workshop I 1 - 22

Database Writer Process (DBWn)
The Database Writer process (DBWn) writes the contents of buffers to data files. The DBWn
processes are responsible for writing modified (dirty) buffers in the database buffer cache to disk.
Although one Database Writer process (DBW0) is adequate for most systems, you can configure
additional processes (DBW1 through DBW9 and DBWa through DBWj) to improve write
performance if your system modifies data heavily. These additional DBWn processes are not useful
on uniprocessor systems.
When a buffer in the database buffer cache is modified, it is marked dirty and is added to the LRUW
(LRU write) list of dirty buffers that is kept in SCN order. This order therefore matches the order of
redo that is written to the redo logs for these changed buffers. When the number of available buffers
in the buffer cache falls below an internal threshold (to the extent that server processes find it
difficult to obtain available buffers), DBWn writes dirty buffers to the data files in the order that they
were modified by following the order of the LRUW list.

Oracle Database 11g: Administration Workshop I 1 - 24

LogWriter Process (LGWR)
The LogWriter process (LGWR) is responsible for redo log buffer management by writing the redo
log buffer entries to a redo log file on disk. LGWR writes all redo entries that have been copied into
the buffer since the last time it wrote.
The redo log buffer is a circular buffer. When LGWR writes redo entries from the redo log buffer to a
redo log file, server processes can then copy new entries over the entries in the redo log buffer that
have been written to disk. LGWR normally writes fast enough to ensure that space is always
available in the buffer for new entries, even when access to the redo log is heavy. LGWR writes one
contiguous portion of the buffer to disk.
LGWR writes:
• When a user pLogWriter process commits a transaction
• When the redo log buffer is one-third full
• Before a DBWn process writes modified buffers to disk (if necessary)

Oracle Database 11g: Administration Workshop I 1 - 26

Checkpoint Process (CKPT)
A checkpoint is a data structure that defines a system change number (SCN) in the redo thread of a
database. Checkpoints are recorded in the control file and in each data file header. They are a crucial
element of recovery.
When a checkpoint occurs, Oracle Database must update the headers of all data files to record the
details of the checkpoint. This is done by the CKPT process. The CKPT process does not write
blocks to disk; DBWn always performs that work. The SCNs recorded in the file headers guarantee
that all changes made to database blocks prior to that SCN have been written to disk.
The statistic DBWR checkpoints displayed by the SYSTEM_STATISTICS monitor in Oracle
Enterprise Manager indicate the number of checkpoint requests that have completed.

Oracle Database 11g: Administration Workshop I 1 - 28

System Monitor Process (SMON)
The System Monitor process (SMON) performs recovery at instance startup if necessary. SMON is
also responsible for cleaning up temporary segments that are no longer in use. If any terminated
transactions were skipped during instance recovery because of file-read or offline errors, SMON
recovers them when the tablespace or file is brought back online.
SMON checks regularly to see whether the process is needed. Other processes can call SMON if they
detect a need for it.

Oracle Database 11g: Administration Workshop I 1 - 29

Process Monitor Process (PMON)
The Process Monitor process (PMON) performs process recovery when a user process fails. PMON
is responsible for cleaning up the database buffer cache and freeing resources that the user process
was using. For example, it resets the status of the active transaction table, releases locks, and
removes the process ID from the list of active processes.
PMON periodically checks the status of dispatcher and server processes, and restarts any that have
stopped running (but not any that Oracle Database has terminated intentionally). PMON also
registers information about the instance and dispatcher processes with the network listener.
Like SMON, PMON checks regularly to see whether it is needed; it can be called if another process
detects the need for it.

Oracle Database 11g: Administration Workshop I 1 - 30

Recoverer Process (RECO)
The Recoverer process (RECO) is a background process that is used with the distributed database
configuration that automatically resolves failures involving distributed transactions. The RECO
process of an instance automatically connects to other databases involved in an in-doubt distributed
transaction. When the RECO process reestablishes a connection between involved database servers,
it automatically resolves all in-doubt transactions, removing from each database’s pending
transaction table any rows that correspond to the resolved in-doubt transactions.
If the RECO process fails to connect with a remote server, RECO automatically tries to connect
again after a timed interval. However, RECO waits an increasing amount of time (growing
exponentially) before it attempts another connection.

Oracle Database 11g: Administration Workshop I 1 - 31

Archiver Processes (ARCn)
The archiver processes (ARCn) copy redo log files to a designated storage device after a log switch
has occurred. ARCn processes are present only when the database is in ARCHIVELOG mode and
automatic archiving is enabled.
If you anticipate a heavy workload for archiving (such as during bulk loading of data), you can
increase the maximum number of archiver processes with the LOG_ARCHIVE_MAX_PROCESSES
initialization parameter. The ALTER SYSTEM statement can change the value of this parameter
dynamically to increase or decrease the number of ARCn processes.

Oracle Database 11g: Administration Workshop I 1 - 32

Other Processes
There are several other background processes that might be running. These can include the
following:
The Manageability Monitor process (MMON) performs various manageability-related background
tasks, for example:
• Issuing alerts whenever a given metrics violates its threshold value
• Taking snapshots by spawning additional process (MMON slaves)
• Capturing statistics value for SQL objects that have been recently modified
The Lightweight Manageability Monitor process (MMNL) performs frequent tasks related to
lightweight manageability, such as session history capture and metrics computation.
The Memory Manager process (MMAN) is used for internal database tasks. It manages automatic
memory management processing to help allocate memory where it is needed dynamically in an effort
to avoid out-of-memory conditions or poor buffer cache performance.

Oracle Database 11g: Administration Workshop I 1 - 33

Server Process and Database Buffer Cache
When a query is processed, the Oracle server process looks in the database buffer cache for images
of any blocks that it needs. If the block image is not found in the database buffer cache, the server
process reads the block from the data file and places a copy in the database buffer cache. Because
subsequent requests for the same block may find the block in memory, the requests may not require
physical reads. Buffers in the buffer cache can be in one of the following four states:
• Pinned: Multiple sessions are kept from writing to the same block at the same time. Other
sessions wait to access the block.
• Clean: The buffer is now unpinned and is a candidate for immediate aging out, if the current
contents (data block) are not referenced again. Either the contents are in sync with the block
contents stored on the disk, or the buffer contains a consistent read (CR) snapshot of a block.
• Free or unused: The buffer is empty because the instance has just started. This state is very
similar to the clean state, except that the buffer has not been used.
• Dirty: The buffer is no longer pinned but the contents (data block) have changed and must be
flushed to the disk by DBWn before it can be aged out.

Oracle Database 11g: Administration Workshop I 1 - 35

Database Storage Architecture
The files that constitute an Oracle database are organized into the following:
• Control files: Contain data about the database itself (that is, physical database structure
information). These files are critical to the database. Without them, you cannot open data files to
access the data in the database.
• Data files: Contain the user or application data of the database, as well as metadata and the data
dictionary
• Online redo log files: Allow for instance recovery of the database. If the database server crashes
and does not lose any data files, the instance can recover the database with the information in
these files.
The following additional files are important to the successful running of the database:
• Parameter file: Is used to define how the instance is configured when it starts up
• Password file: Allows sysdba, sysoper, and sysasm to connect remotely to the database
and perform administrative tasks
• Backup files: Are used for database recovery. You typically restore a backup file when a media
failure or user error has damaged or deleted the original file.
• Archived redo log files: Contain an ongoing history of the data changes (redo) that are
generated by the instance. Using these files and a backup of the database, you can recover a lost
data file. That is, archive logs enable the recovery of restored data files.

Oracle Database 11g: Administration Workshop I 1 - 36

Logical and Physical Database Structures
The database has logical structures and physical structures.
Tablespaces
A database is divided into logical storage units called tablespaces, which group related logical
structures together. For example, tablespaces commonly group all of an application’s objects to
simplify some administrative operations. You may have a tablespace for application data and an
additional one for application indexes.
Databases, Tablespaces, and Data Files
The relationship among databases, tablespaces, and data files is illustrated in the slide. Each database
is logically divided into one or more tablespaces. One or more data files are explicitly created for
each tablespace to physically store the data of all logical structures in a tablespace. If it is a
TEMPORARY tablespace instead of a data file, the tablespace has a temporary file.

Oracle Database 11g: Administration Workshop I 1 - 38

Tablespaces and Data Files
A database is divided into tablespaces, which are logical storage units that can be used to group
related logical structures. Each database is logically divided into one or more tablespaces. One or
more data files are explicitly created for each tablespace to physically store the data of all logical
structures in a tablespace.
Note: You can also create bigfile tablespaces, which have only one file that is often very large. The
file may be any size up to the maximum that the row ID architecture permits. The maximum size is
the block size for the tablespace multiplied by 236, or 128 TB for a 32 KB block size. Traditional
smallfile tablespaces (which are the default) usually contain multiple data files, but the files cannot
be as large. For more information about bigfile tablespaces, see the Oracle Database Administrator’s
Guide.

Oracle Database 11g: Administration Workshop I 1 - 40

SYSTEM and SYSAUX Tablespaces
Each Oracle database must contain a SYSTEM tablespace and a SYSAUX tablespace, which are
automatically created when the database is created. The system default is to create a smallfile
tablespace. You can also create bigfile tablespaces, which enable the Oracle database to manage
ultralarge files (up to 8 exabytes in size).
A tablespace can be online (accessible) or offline (not accessible). The SYSTEM tablespace is always
online when the database is open. It stores tables that support the core functionality of the database,
such as the data dictionary tables.
The SYSAUX tablespace is an auxiliary tablespace to the SYSTEM tablespace. The SYSAUX
tablespace stores many database components, and it must be online for the correct functioning of all
database components.
Note: The SYSAUX tablespace may be offlined to do tablespace recovery, whereas this is not
possible for the SYSTEM tablespace. Neither of them may be made read-only.

Oracle Database 11g: Administration Workshop I 1 - 41

Segments, Extents, and Blocks
Database objects such as tables and indexes are stored as segments in tablespaces. Each segment
contains one or more extents. An extent consists of contiguous data blocks, which means that each
extent can exist only in one data file. Data blocks are the smallest unit of I/O in the database.
When the database requests a set of data blocks from the operating system (OS), the OS maps this to
an actual file system or disk block on the storage device. Because of this, you do not need to know
the physical address of any of the data in your database. This also means that a data file can be
striped or mirrored on several disks.
The size of the data block can be set at the time of database creation. The default size of 8 KB is
adequate for most databases. If your database supports a data warehouse application that has large
tables and indexes, a larger block size may be beneficial.
If your database supports a transactional application in which reads and writes are random,
specifying a smaller block size may be beneficial. The maximum block size depends on your OS.
The minimum Oracle block size is 2 KB; it should rarely (if ever) be used.
You can have tablespaces with a nonstandard block size. For details, see the Oracle Database
Administrator’s Guide.

Oracle Database 11g: Administration Workshop I 1 - 42

Database Architecture: Summary of Structural Components
In this lesson, you learned at a high level about the structural components of the Oracle database:
memory, process, and storage structures. The details are covered in the following lessons.

Oracle Database 11g: Administration Workshop I 1 - 43

Oracle Database 11g: Administration Workshop I 1 - 44
Oracle Database 11g: Administration Workshop I 1 - 45