You are on page 1of 15

UMEME

Template Version 1.0

Oracle Database Architecture


Version 1

Copyright UMEME 2013


Copyright protects this publication. Except for purposes permitted by the Copyright Act, reproduction by whatever
means is prohibited without the prior written permission of UMEME Ltd. Inquiries should be addressed to the Chief
Information Officer, UMEME.
Commercial-in-confidence
This document may contain commercial-in-confidence information. The document has been produced for the sole use
of UMEME, and should not be provided to external organisations without the written approval of the Chief Information
Officer, UMEME.

Page 1 of 15

UMEME

Template Version 1.0

Document Management Information


Document Title

:Oracle Database Architecture

Document Status

: Draft / Review / Approval / Final

Document Publication History


(All revisions made to this document must be listed in chronological order)
Version

Date

Author(s)

Remarks

1.0

02/01/2014

Geoffrey Musafu

Intial Document

Document Review and Approval History


(All revisions must be approved. Review and Approval can be done by an internal source
or by the customer)
Version

Date

Reviewer & Approver

Designatioin

Signature

V.1.0

Morayo Oyisemi

Software Services
Manager

V.1.0

Moses Bukenya

Infrastructure Manager

V.1.0

Nelson Bagenda

Service Delivery Manager

V.1.0

Earmon Furniss

CIO

Page 2 of 15

1 Overview
Oracle server consists of an Oracle instance and an Oracle database. An Oracle
instance consists of a memory structure, called the System Global Area (SGA), and
background processes used by an Oracle server to manage a database. An Oracle
instance is identified by setting ORACLE_SID at the operating system. Briefly:
Oracle Server = Oracle Instance and Oracle Database
Instance = SGA Memory and Background processes
Database = physical files (data, redo, and control)
1.1 Oracle Architecture (NON RAC)

1.2 Oracle Architecture (RAC)

UMEME

Template Version 1.0

2. System Global Area


The memory structures of an Oracle instance are contained in a memory region called the
SGA, which contains data and control information for the Oracle server. The SGA is
allocated in the virtual memory of the computer where the Oracle server resides. The
SGA comprises several memory structures, including:
Shared pool: used to store information such as the most recently executed SQL and
the most recently used data from the data dictionary. It consists of Library Cache and
Data Dictionary Cache.

Database buffer cache: used to store the most recently used data
Redo log buffer: used to register changes made to the database using the instance
2.1 Background Processes
The background processes in an instance perform common functions that are needed to
service the requests from several concurrent users, without compromising the integrity
and performance of the whole system. Each Oracle instance may use several background
Confidential

Page 4 of 15

UMEME

Template Version 1.0

processes, depending on the configuration, but every instance comprises these five
background processes by default:

Database Writer (DBWR): responsible for writing changed data to the database

Log Writer (LGWR): records changes registered in the redo log buffer to the
database

System Monitor (SMON): whose primary function is to check for consistency


and initiate recovery of the database when the database is opened

Process Monitor (PMON): cleans up the resources if one of the processes fails

Checkpoint process (CKPT): responsible for updating the database status


information whenever changes in the buffer cache are permanently recorded in the
database

2.2 RAC Background Processes

LMON - The Global Enqueue Service Monitor (LMON) monitors the entire
cluster to manage the global enqueues and the resources. LMON manages
instance and process failures and the associated recovery for the Global Cache
Service (GCS) and Global Enqueue Service (GES). In particular, LMON handles
the part of recovery associated with global resources. LMON-provided services
are also known as cluster group services (CGS).
LMDx - The Global Enqueue Service Daemon (LMD) is the lock agent process
that manages enqueue manager service requests for Global Cache Service
enqueues to control access to global enqueues and resources. The LMD process
also handles deadlock detection and remote enqueue requests. Remote resource
requests are the requests originating from another instance.
GSC GLOBAL CLUSTER SERVICES IS ACROSS INCTENCES AND
PROVIED INFORMATION WHERE EVER REQUERD.
RBAL - The RBAL background process in the RDBMS instance performs global
opens to the disks in the diskgroups in the database instance. Note that there is
also an RBAL background process in the ASM Instance that has a completely
different purpose.
LMSw - The Global Cache Service background processes (LMS/7) manage
requests for data access between the nodes of the cluster..
LCKO - The instance enqueue background process (LCKO) is part of GES. It
manages requests for resources other than data blocksfor example, library and
row cache objects. LCK processes handle all resource transfers not requiring
Cache Fusion. It also handles cross-instance call operations.
DIAG - The DIAG background process captures diagnostic information when
either a process or the entire instance fails. This information is written to a
subdirectory
within
the
directory
specified
by
the
BACKGROUND_DUMP_DEST initialization parameter. The files generated by
this process can be forwarded to Oracle Support for further analysis.

Confidential

Page 5 of 15

UMEME
2.3

Template Version 1.0

Oracle Database

An Oracle database, identified by the database name (DB_NAME), represents the


physical structures and is composed of operating system files. Although it is possible to
use a database name that is different from the name of the instance, Oracle recommends
that the same name be used for ease of administration.
2.4

Database Files

The files constituting a database contain user data and the additional information that is
needed to ensure proper database operation.
An Oracle database consists of the following types of files:

Data files: store the data dictionary, user objects, and before-images of data that are
modified by current transactions. A database has at least one data file
Redo log files: contain a record of changes made to the database to ensure
reconstruction of the data in case of failures (A database requires at least two redo log
files.)
Control files: contain the information needed to maintain and verify database
integrity (A database needs at least one control file.)

1.1.1.1 2.5 Other Key Physical Structures


Apart from the database files, an Oracle server also uses other files. Some of these are:

Parameter file: used to define the characteristics of an Oracle instance


Password file: used to authenticate privileged database users
Archived redo log files: offline copies of the redo log files that may be necessary
to recover from media failures

1.1.1.2 2.6 Shared Pool

The shared pool is a part of the SGA that is used during the parse phase. The size of the
shared pool is specified by the initialization parameter, SHARED_POOL_SIZE in the
parameter file. The components of the shared pool described below are used to parse an
SQL statement.
Library Cache

Confidential

Page 6 of 15

UMEME

Template Version 1.0

The library cache stores the following information about the most recently used SQL
statements:

Text of the statement


Parse tree, which is the compiled version of the statement
Execution plan, which defines the steps to be followed in running the
Statement as determined by the optimizer

Since the library cache stores this information, if a query is re-executed before its
execution plan is aged out by other statements, the server process does not need to
parse the statement. Thus the library cache helps improve the performance of
applications.

2.7 Data Dictionary Cache


The data dictionary cache, also known as the dictionary cache or row cache, is a part of
the shared pool that stores the most recently used data dictionary information, such as
table and column definitions, usernames, passwords, and privileges.
During the parse phase, the server process looks for the information in the dictionary
cache to resolve the object names specified in the SQL statement and to validate the
access privileges. If necessary, the server process initiates the loading of this information
from the data files.
1.1.1.3

2.8 Database Buffer Cache

When a query is processed, the server process looks for the blocks needed in the database
buffer cache. If the block is not found in the database buffer cache, the server process
reads the block from the data file and places a copy in the buffer cache. Subsequent
requests for the same block are likely to find the block in memory, and may not require
physical reads.

1.1.1.3.1
2.9 Function of the Database Buffer Cache
The database buffer cache, or simply the buffer cache, is an area in the SGA that is used
to store the most recently used data blocks. The size of each buffer in the buffer cache is
equal to the size of a data block, and it is specified by the DB_BLOCK_SIZE parameter.
The number of buffers is equal to the value of the DB_BLOCK_BUFFERS parameter.
The Oracle server uses least recently used (LRU) algorithm to age out buffers that have
not been accessed recently to make way for new blocks to be accommodated in the buffer
cache.
Confidential

Page 7 of 15

UMEME

Template Version 1.0

1.1.1.4 2.10 Redo Log Buffer

The server process records changes made by an instance in the redo log buffer, which is a
part of the SGA. The redo log buffer has the following characteristics:

Its size in bytes is defined by the LOG_BUFFER init.ora parameter.

It stores redo records, which record changesthat is, the block that is changed,
the location of the change, and the new value. A redo entry registers a change, but it
makes no distinction between the type of block that is changed. So it cannot
distinguish, for example, a change to a data block from a change to an index or a
rollback block.

The redo log buffer is used sequentially, and changes made by one transaction
may be interleaved with changes made by other transactions.

It is a circular buffer that is reused after it is filled up, but only after all the old
redo entries are recorded in the redo log files.

2.11 Database Writer (DBWR)


The server process records changes to rollback and data blocks in the buffer cache. The
database writer (DBWR) writes the dirty buffers from the database buffer cache to the
data files. It ensures that sufficient number of free buffersbuffers that can be
overwritten when server processes need to read in blocks from the data filesare
available in the database buffer cache. Database performance is improved because server
processes only make changes in the buffer cache, and the DBWR defers writing to the
data files until one of the following events occur:

The number of dirty buffers reaches a threshold value

A process scans a specified number of blocks when scanning for free buffers and
cannot find any

A timeout occurs

A DBWR checkpoint can be triggered by various events such as closing of the


database, (Checkpoint is a means of synchronizing the database buffer cache with the
data file.)
2.12 Log Writer (LGWR)
The Log Writer (LGWR) is a background process that writes entries from the redo log
buffer into the redo log files. The LGWR performs sequential writes to the redo log file
under the following situations:

When the redo log buffer is one-third full

When a timeout occurs (every three seconds)

Before DBWR writes modified blocks in the database buffer cache to the data
files
Confidential

Page 8 of 15

UMEME

Template Version 1.0

When a transaction commits

3 Programs Global Area (PGA)


The Program Global Area (PGA) is a memory region that contains data and controls
information for a single server process or a single background process. In contrast to the
SGA, this is shared and written to by several processes, the PGA, which is also called the
process global area, is an area that is used by only one process. When using the dedicated
server configuration, the PGA contains:

Sort area: which is used for any sort that may be necessary before rows are
processed or returned to the user

Session information: such as user privileges for the session

Cursor state: which indicates the stage in the processing of various cursors that
are currently used by the session

Stack space: containing the session variables


The PGA is allocated when a process is created and de-allocated when the process is
terminated.
1.1.1.5 3.1 Rollback Segment

Before making a change, the server process saves the old value into a rollback segment.
This image is used to:

Undo the changes if the transaction is rolled back

Ensure that other transactions do not see uncommitted changes made by the DML
statement (read consistency)

Recover the database to a consistent state in case of failures


Rollback segments, like tables and indexes, exist in data files and parts of them are
brought into the database buffer cache when required

1.1.2

4. Logical Database Structure

An ORACLE database's logical structure is determined by:


One or more tablespaces.
The database's schema objects (e.g. tables, views, indexes, clusters, sequences, stored
procedures).

Confidential

Page 9 of 15

UMEME

Template Version 1.0

The logical storage structures, including tablespaces, segments, and extents, dictate
how the physical space of a database is used. The schema objects and the relationships
among them form the relational design of a database.

4.1 Tablespaces and Data Files


Tablespaces are the primary logical storage structures of any ORACLE database. The
usable data of an ORACLE database is logically stored in the tablespaces and physically
stored in the data files associated with the corresponding tablespace. Figure 2 illustrates
this relationship.

Every ORACLE database contains a tablespace named SYSTEM, which is automatically


created when the database is created. The SYSTEM tablespace always contains the data
dictionary tables for the entire database. You can query these data dictionary tables to
obtain pertinent information about the database.
After a data file is initially created, the allocated disk space does not contain any data;
however, the space is reserved to hold only the data for future segments of the associated
tablespace - it cannot store any other program's data. As a segment (such as the data
segment for a table) is created and grows in a tablespace, ORACLE uses the free space in
the associated data files to allocate extents for the segment.
The data in the segments of objects (data segments, index segments, rollback segments,
and so on) in a tablespace are physically stored in one or more of the data files that
constitute the tablespace. Note that a schema object does not correspond to a specific data
file; rather, a data file is a repository for the data of any object within a specific
tablespace. The extents of a single segment can be allocated in one or more data files of a
tablespace (see Figure 3); therefore, an object can span one or more data files. The
database administrator and end-users cannot control which data file stores an object.
4.2 Data Blocks, Extents, and Segments

Confidential

Page 10 of 15

UMEME

Template Version 1.0

ORACLE allocates database space for all data in a database. The units of logical
database allocations are data blocks, extents, and segments. Figure 3 illustrates the
relationships between these data structures.

4.3 Extents

The next level of logical database space is called an extent. An extent is a specific
number of contiguous data blocks that are allocated for storing a specific type of
information.
4.4 Segments

The level of logical database storage above an extent is called a segment. A segment
is a set of extents which have been allocated for a specific type of data structure, and
all are stored in the same tablespace. 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.
ORACLE allocates space for segments in extents. Therefore, when the existing
Confidential

Page 11 of 15

UMEME

Template Version 1.0

extents of a segment are full, ORACLE allocates another extent for that segment.
Because extents are allocated as needed, the extents of a segment may or may not be
contiguous on disk, and may or may not span files. An extent cannot span files,
though.
4.5 Data Blocks
At the finest level of granularity, an ORACLE database's data is stored in data blocks
(also called logical blocks, ORACLE blocks, or pages). An ORACLE database uses
and allocates free database space in ORACLE data blocks. Figure 4 illustrates a
typical ORACLE data block.
A data block is the smallest unit of I/O used by a database. A data block corresponds
to a block of physical bytes on disk, equal to the ORACLE data block size
(specifically set when the database is created - 2048). This block size can differ from
the standard I/O block size of the operating system that executes ORACLE.
The ORACLE block format is similar regardless of whether the data block contains
table, index, or clustered data. Figure 4 shows the format of a data block.

4.6 Header (Common and Variable)

Confidential

Page 12 of 15

UMEME

Template Version 1.0

The header contains general block information, such as block address, segment type,
such as data, index, or rollback. While some block overhead is fixed in size (about
107 bytes), the total block overhead size is variable.
4.7 Table Directory
The table directory portion of the block contains information about the tables having
rows in this block.
4.8 Row Directory
This portion of the block contains row information about the actual rows in the block
(including addresses for each row piece in the row data area). Once the space has
been allocated in the row directory of a block's header, this space is not reclaimed
when the row is deleted.
4.9 Row Data
This portion of the block contains table or index data. Rows can span blocks.
4.10 Free Space
Free space is used to insert new rows and for updates to rows that require additional
space (e.g., when a trailing null is updated to a non-null value). Whether issued
insertions actually occur in a given data block is a function of the value for the space
management parameter PCTFREE and the amount of current free space in that data
block.
4.11 Space Used for Transaction Entries
Data blocks allocated for the data segment of a table, cluster, or the index segment of
an index can also use free space for transaction entries.
Two space management parameters, PCTFREE and PCTUSED, allow a developer to
control the use of free space for inserts of and updates to the rows in data blocks.
Both of these parameters can only be specified when creating or altering tables and
clusters (data segments). In addition, the storage parameter PCTFREE can also be
specified when creating or altering indices (index segments).
The PCTFREE parameter is used to set the percentage of a block to be reserved (kept
free) for possible updates to rows that already are contained in that block. For
example, assume that you specify the following parameter within a CREATE TABLE
statement:
Pctfree 20

Confidential

Page 13 of 15

UMEME

Template Version 1.0

This states that 20% of each data block used for this table's data segment will be kept
free and available for possible updates to the existing rows already within each block.
After a data block becomes full, as determined by PCTFREE, the block is not
considered for the insertion of new rows until the percentage of the block being used
falls below the parameter PCTUSED. Before this value is achieved, the free space of
the data block can only be used for updates to rows already contained in the data
block. For example, assume that you specify the following parameter within a
CREATE TABLE statement:
pctused 40
In this case, a data block used for this table's data segment is not considered for the
insertion of any new rows until the amount of used space in the blocks falls to 39% or
less (assuming that the block's used space has previously reached PCTFREE).
No matter what type, each segment in a database is created with at least one extent to
hold its data. This extent is called the segment's initial extent.
If the data blocks of a segment's initial extent become full and more space is required
to hold new data, ORACLE automatically allocates an incremental extent for that
segment. An incremental extent is a subsequent extent of the same or incremented
size of the previous extent in that segment.
Every non-clustered table in an ORACLE database has a single data segment to hold
all of its data. The data segment for a table is indirectly created via the CREATE
TABLE/SNAPSHOT command.
Storage parameters for a table, snapshot, or cluster control the way that data
segments extents are allocated. Setting these storage parameters directly via the
CREATE TABLE/SNAPSHOT/CLUSTER or ALTER
TABLE/SNAPSHOT/CLUSTER commands affects the efficiency of data retrieval
and storage for that data segment.

Confidential

Page 14 of 15

UMEME

Template Version 1.0

4.12 Physical Database Structure


An ORACLE database's physical structure is determined by the operating system
files that constitute the database. Each ORACLE database is comprised of these types
of files: one or more data files, two or more redo log files, and one or more control
files. The files of a database provide the actual physical storage for database
information.

Confidential

Page 15 of 15

You might also like