IN ORACLE MILIEU …

April 9, 2008
Oracle Database 9i – Basic Architecture
Filed under: Oracle Database 9i — advait @ 7:13 pm
Tags: architecure, oracle 9i, Oracle 9i architecture, oracle architecure 9i, Oracle Database 9i,
Oracle database 9i architecture
Introduction
This post is regarding the basic database architecture for 9i. Its been very late to upload this basic
stuff, but I realized that it would be an incomplete blog without having even a brief architecture.
So here it is.
Below is the figure which gives a overview of “Inside Oracle”.

An Oracle database is a combination of oracle Instance and data files on the file system.
Oracle Database = Oracle Instance + Datafiles
Again Oracle Instance is nothing but Memory architecture and Background processes. Lets start
the discussion with Memory architecture first.
Memory Architecture
Oracle database uses memory for its operation. The total memory allocated to the Oracle
database can be broadly categorized into SGA (System Global Area) and PGA (Program Global
Area).
SGA Contains following data structure
• Database buffer cache
• Redo log buffer
• Shared pool
• Java pool
 • Large pool (optional)
• Data dictionary cache
• Other miscellaneous information
We can also categorized SGA into fixed SGA and variable SGA. When asked about Fixed SGA,
AskTom says that “fixed SGA is a component of the SGA that varies in size from platform to
platform and release to release. It is “compiled “ into the database. The fixed SGA contains a
set of variables that point to the other components of the SGA and 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.”
Variable SGA contains 4 main components as listed above, those are “Database Buffer Cache”,
“Redo Log Buffer”, “Shared Pool” and “Large Pool”. We call it variable SGA because we can
alter the size of each of these components manually using ALTER SYSTEM command. The size
of each of the components of variable SGA is determined by INIT.ORA parameters. Following
are the INIT.ORA parameter for each of the component.
• Database Buffer Cache – db_block_buffers
• Redo Log Buffer – log_buffer
• Shared Pool – shared_pool_size
• Large Pool – Large_pool_size
We cannot however alter the size of Fixed SGA.
Database Buffer Cache – This is used to hold the data into the memory. When ever a user
access the data, it gets fetched into database buffer cache and it will be managed according to
LRU (Least recently used) algorithm. Advantages – If a user is requesting data, which gets
fetched into the buffer cache, then next time if he ask for same data with in a short period of
time, the data will be read from buffer cache and Oracle process does not have to fetch data
again from disk. Reading data from buffer cache is a faster operation. Another advantage is that
if a user is modifying the data, it can be modified in the buffer cache which is a faster operation
then modifying the data directly on the disk.
Redo Log Buffer - This memory block hold the data which is going to be written to redo log
file. Why do we need this data? To rollback the changes if the need be. But instead of writing the
data directly to the redo log files, it is first written to log buffer which improves performance and
then with the occurrence of certain event it will be written to redo log file.
Shared Pool - This contains 2 memory section, 1) Library Cache 2) Dictionary Cache. Library
cache hold the parsed SQL statement and execution plans and parsed PLSQL codes. Dictionary
cache hold the information about user privileges, tables and column definitions, passwords etc.
These 2 memory components are included in the size of shared pool.
Large Pool - If defined then used for heavy operations such as bulk copy during backup or
during restore operation.
The total size of SGA is determined by a parameter SGA_MAX_SIZE. Below is the simple
calculation of memory sizes.
SQL> show sga
Total System Global Area 577574308 bytes
Fixed Size 452004 bytes
Variable Size 402653184 bytes
Database Buffers 163840000 bytes
Redo Buffers 10629120 bytes
This will show fixed and variable size SGA. Fixed size SGA, as I said is not in our control.
However we can verify the size of variable SGA and other memory values shown above.
Database Buffers 163840000 bytes
SQL> show parameters db_block_buffer
NAME TYPE VALUE
———————————— ———– ——————————
db_block_buffers integer 20000
This value is in terms of blocks. we can find the size of a block using DB_BLOCK_SIZE
parameter
SQL> show parameters db_block_size
NAME TYPE VALUE
———————————— ———– ——————————
db_block_size integer 8192
So Database Buffers = db_block_buffers X db_block_size = 20000 X 8192 = 163840000 bytes
Also Variable size = “Shared Pool Size” + “Large Pool Size” + “Java Pool size” (some times
defined)
SQL> SELECT pool, sum(bytes) from v$sgastat group by pool;
POOL SUM(BYTES)
———– ———-
java pool 50331648
shared pool 352321536
11069860
Variable size = 352321536 + 50331648 = 402653184 bytes
Program Global Area
PGA contains information about bind variables, sort areas, and other aspect of cursor handling.
This is not a shared area and every user has its own PGA. But why PGA is required for every
user? The reason being that even though the parse information for SQL or PLSQL may be
available in library cache of shared pool, the value upon which the user want to execute the
select or update statement cannot be shared. These values are stored in PGA. This is also called
Private Global Area.
Going still deeper into the memory structure…
Database buffer cache is again divided into 3 different types of cache.
1. Default Cache
2. Keep Cache
3. Recycle Cache
If we define the cache size using DB_CACHE_SIZE (or DB_BLOCK_BUFFER and specify the
block size) then this will be default cache. The cache has a limited size, so not all the data on
disk can fit in the cache. When the cache is full, subsequent cache misses cause Oracle to write
dirty data already in the cache to disk to make room for the new data.
You can configure the database buffer cache with separate buffer pools that either keep data in
the buffer cache or make the buffers available for new data immediately after using the data
blocks.
• The KEEP buffer pool retains the schema object’s data blocks in memory. This is defined
using the INIT.ORA parameter DB_KEEP_CACHE_SIZE
• The RECYCLE buffer pool eliminates data blocks from memory as soon as they are no
longer needed. This is defined using the INIT.ORA parameter DB_RECYCLE_CACHE_SIZE
You can also define multiple DB block sizes using following parameters. Example if you have
defined standard default block size of 4K, then following parameters can be used to define a size
of 2K, 8K, 16K and 32K.
DB_2K_CACHE_SIZE
DB_8K_CACHE_SIZE
DB_16K_CACHE_SIZE
DB_32K_CACHE_SIZE
Note that you can define the Keep and Recycle cache only on standard block size and buffer
cache size is the sum of sizes of each of these pools.
Shared Pool Reserved Size
Shared Pool, as we have seen previously contains the parsed SQL statements and execution
plans. With continuous use of database, after a period of time the shared pool will get
fragmented. New parsed SQL and execution plans comes and old one gets aged out and hence
overwritten. This will also lead to larger packages being aged out with new entries going into
shared pool. Hence access to such larger packages will take time to parse and create execution
plan. This might cause performance issues.
To avoid such situation, you can define a parameter SHARED_POOL_RESERVED_SIZE. This
will reserve some additional space other then shared_pool_size. If an object (either parsed SQL
statement or execution plan) is stored in reserved shared pool area then it will not age out.
For large allocations, the order in which Oracle attempts to allocate space in the shared pool is
the following:
1. From the unreserved part of the shared pool.
2. If there is not enough space in the unreserved part of the shared pool, and if the allocation
is large, then Oracle checks whether the reserved pool has enough space.
3. If there is not enough space in the unreserved and reserved parts of the shared pool, then
Oracle attempts to free enough memory for the allocation. It then retries the unreserved
and reserved parts of the shared pool.
Process Architecture
Oracle has several process running in the background for proper functioning of database.
Following are the main categories of process.
1. Server Process
 2. Background Process
Server Process – to handle the requests of user processes connected to the instance. Server
processes (or the server portion of combined user/server processes) created on behalf of each
user’s application can perform one or more of the following:
• Parse and execute SQL statements issued through the application
• Read necessary data blocks from datafiles 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 Process - An Oracle instance can have many background processes; not all are
always present. The background processes in an Oracle instance include the following:
• Database Writer (DBW0 or DBWn)
• Log Writer (LGWR)
• Checkpoint (CKPT)
• System Monitor (SMON)
• Process Monitor (PMON)
• Archiver (ARCn)
• Recoverer (RECO)
• Lock Manager Server (LMS) – Real Application Clusters only
• Queue Monitor (QMNn)
• Dispatcher (Dnnn)
• Server (Snnn)
On many operating systems, background processes are created automatically when an instance is
started.
Database writer (DBWn) - The database writer process (DBWn) writes the contents of buffers
to datafiles. 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) to improve write
performance if your system modifies data heavily. These additional DBWn processes are not
useful on uniprocessor systems.
Log Writer (LGWR) – The log writer process (LGWR) is responsible for redo log buffer
management–writing the redo log buffer 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.
Checkpoint (CKPT) - When a checkpoint occurs, Oracle must update the headers of all datafiles
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.
System Monitor (SMON) – The system monitor process (SMON) performs crash recovery, if
necessary, at instance startup. SMON is also responsible for cleaning up temporary segments that
are no longer in use and for coalescing contiguous free extents within dictionary-managed
tablespaces. If any dead transactions were skipped during crash and instance recovery because of
file-read or offline errors, SMON recovers them when the tablespace or file is brought back
online. SMON wakes up regularly to check whether it is needed.
Process Monitor (PMON) -
The process monitor (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 died (but not any that Oracle has terminated intentionally). PMON also registers
information about the instance and dispatcher processes with the network listener.
Archiver Process (ARCn) -
The archiver process (ARCn) copies online 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.
An Oracle instance can have up to 10 ARCn processes (ARC0 to ARC9). The LGWR process
starts a new ARCn process whenever the current number of ARCn processes is insufficient to
handle the workload. The ALERT file keeps a record of when LGWR starts a new ARCn
process.
Recoverer (RECO) – The recoverer process (RECO) is a background process used with the
distributed database configuration that automatically resolves failures involving distributed
transactions. The RECO process of a node 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.
The RECO process is present only if the instance permits distributed transactions and if the
DISTRIBUTED_TRANSACTIONS parameter is greater than zero. If this initialization parameter is
zero, RECO is not created during instance startup.
Lock Manager Server (LMS) - In Oracle9i Real Application Clusters, a Lock Manager Server
process (LMS) provides inter-instance resource management.
Queue Monitor (QMNn) – The queue monitor process is an optional background process for
Oracle Advanced Queuing, which monitors the message queues. You can configure up to 10
queue monitor processes. These processes, like the Jnnn processes, are different from other
Oracle background processes in that process failure does not cause the instance to fail.
The above once explained are the mail background processes. Please refer to the Oracle
documentation for detailed Oracle 9i Architecture.
Hope this helps !!
References:
Oracle9i Database Online Documentation (Release 9.0.1)