Architecture
Architecture
created and marketed. It is one of the most popular RDBMSs on the market and is used to store
and retrieve data for a wide range of applications. Oracle Database is well-known for its
dependability, scalability, and performance, and it is compatible with a wide range of programming
languages and development frameworks. It includes data warehousing, online transaction
processing, and advanced analytics, as well as high availability, disaster recovery, and security.
Oracle Database employs a client-server architecture, with the database server and client
connections running in separate processes. The server process manages data and resources, and
client connections communicate with the server to access and manipulate data. SQL, PL/SQL
(Oracle’s proprietary procedural language), and Java are among the programming interfaces
supported by Oracle Database. It also includes tools for database management and administration,
such as Oracle Enterprise Manager and SQL Plus.
The oracle database architecture consists of:
Memory structure(Instances)
Database system
Processes
Oracle Instances
Database buffer cache: The Buffer Cache is a portion of the SGA that stores copies of data
blocks read from datafiles. It is used to cache frequently accessed data blocks, reducing the
number of disks I/Os required to access the data. This can improve performance by reducing
disk I/O time and increasing the speed of data retrieval.
Redo log Buffer: The most crucial structure for recovery operations is the redo log, which
consists of two or more preallocated files that store all changes made to the database as they
occur. Every instance of an Oracle Database has an associated redo log to protect the
database in case of an instance failure.
Java pool: The Java Pool is an optional portion of the SGA that is used by Java Virtual
Machine (JVM) and related components. It is used to store Java-related data structures, such
as Java classes and objects. This pool is used when the Oracle Database is configured to run
Java applications or when using Oracle JVM.
Large Pool: The Large Pool is an optional portion of the SGA that can be used for large
memory allocation, such as backup and restore operations and I/O server processes. It is
typically used to improve the performance of these operations by reducing the amount of disk
I/O required.
Shared pool: The Shared Pool is a portion of the SGA that contains shared memory structures,
such as shared SQL and PL/SQL areas. It is used to store the parsed representation of SQL
statements, execution plans, and PL/SQL program units. This allows for the efficient reuse of
frequently executed statements, reducing the need for reparsing and improving performance.
Background processes: Oracle has a collection of processes that are called background
processes. These processes are responsible for managing memory, performing I/O operations, and
other maintenance activities. Following are some important background processes that are
required:
System Monitor Process (SMON): These processes are responsible for performing system-
level recovery and maintenance activities.
Database Writer Process (DBWR): This process performs the task of writing data blocks from
the Database Buffer Cache (present in SGA) to physical data files(Present in the Database
system).
Log Writer Process (LGWR): This process writes the Redo blocks from Redo Log Buffer
(present in SGA) to Redo Log Files(present in the Database system).
CheckPoint (CKPT): This process maintains data files and control files with the most recent
checkpoint information.
A checkpoint occurs when: 1. A log switch occurs 2. Instance is shutdown normal, transactional, or
immediate 3. As dictated by the LOG_CHECKPOINT_INTERVAL (specified as a number of O/S blocks.
Checkpoint starts when this number of O/S blocks have specified have been written by LGWR. If
value exceeds redo log file size checkpoint will only occur at logswitch) and
LOG_CHECKPOINT_TIMEOUT ( specify as a number of seconds. If set to zero (0) disables timeout
checkpoints) parameters. 4. Requested on the fly by the dba. Set the LOG_CHECKPOINTS_TO_ALERT
= TRUE to log all checkpoints to the alter file
Database System
The database system is suited to the storage system of a computer. The Database system is simply
the storage of files. There are three categories of files that are situated in the database system and
those are:-
Data files: These files hold the actual data in the database.
Redo log files: These files are used to hold the changes made in the database. Redo log files
can be utilized during the database recovery process to retrieve the original information.
Control files: It is a binary file that holds database status-related information like Database
Name, Data File, and Redo Log file Names, File Locations, and Log Sequence Number.
There are other categories of files that contribute to database management.
Parameter file: This file contains the parameters which define the way the database is
expected to start up.
Password file: This file holds the user passwords and thus maintains the security of
databases.
Processes
SMON (System Monitor) • Performs automatic instance recovery • Reclaims space used by
temporary segments no longer in use • Merges contiguous areas of free space in the datafiles.
Known as defragging or coalescing
PMON (Process Monitor) • Cleans up abnormally terminated user sessions • Rolls back any
uncommitted transactions • Releases locks held by a terminated process • Frees SGA
resources allocated to the failed process • Restarts failed shared server and dispatcher
processes • Identified
DBWR (Database Writer) • Writes all changed (i.e. dirty) buffers to datafiles. • Uses a LRU
(least recently used) algorithm to keep most recently used blocks in memory. • Defers writes
for I/O optimization.
* LGWR – Log Writer process is responsible for writing the log buffers out
to the redo logs. In RAC, each RAC instance has its own LGWR process that
maintains that instance?s thread of redo logs.
LGWR (Log Writer) - Writes information from the redo log buffer to the redo log files. •
There is only one redo log writer per instance. • A commit confirmation is not issued until the
transaction has been recorded in the redo log file. • Commits performed by other users before
LGWR flushes the buffer on behalf of a user's commit are piggybacked to achieve an
average of less than one I/O per commit. • During very long transactions, the redo log buffer
pool can become more than one-third full before LGWR writes it to the redo log file. Will
write redo log buffer entries to the redo log files when: 1. A commit occurs. 2. The redo log
buffer pool becomes one-third full. 3. The DBWR completes cleaning the buffer blocks as
during a checkpoint. 4. A LGWR time-out occurs(every 3 seconds).
* ARCH ? The optional Archive process writes filled redo logs to the archive
log location(s). In RAC, the various ARCH processes can be utilized to
ensure that copies of the archived redo logs for each instance are available
to the other instances in the RAC setup should they be needed for recovery.
ARCH (Archiver Process) copies online redo log files to a designated storage device when
LGWR switches to a new group. • Copies redo log files to tape or disk for media failure
recovery. • Operates only when a log switch occurs. • Is only needed when the database is
running in ARCHIVELOG mode.
The Log Writer Process (LGWR) is responsible for the movement of this
redo.
Advertisement
The LGWR process is started when the database is started, and shutdown
when the database is shutdown. On regular intervals LGWR will move the
redo from the redo log buffer to files on disk designed to store the redo
called online redo log files.
The Database Writer (DBWR) process is responsible for writing data from
the RAM buffer cache to the database datafiles on disk. The database
datafiles are physical files on disk The default is to have one database
writer process, but large databases can have multiple DBWR processes.
The Process Monitor is the janitor of the database, cleaning-up trash left-
over from aborted user sessions (for instance, if a client abnormally
disconnects from the database). If this should happen, it is the job of the
Process Monitor (PMON) process to cleanup after that failure. PMON will
cleanup memory areas and other database resources that were in use by
that user process. PMON constantly checks the status of user and database
processes. In some cases, failed database processes can be restarted by
PMON.
When you startup your Oracle database, Oracle will perform several checks
to see if the database is healthy. SMON manages your database for you!
A Program Global Area (PGA) is a memory region that contains data and
control information for a server process. It is a non-shared memory region
created by Oracle when a server process is started. Access to the PGA is
exclusive to that server process and it is read and written only by Oracle
code acting on its behalf. It contains a private SQL area and a session
memory area.
A private SQL area contains data such as bind information and runtime
memory structures. Each session that issues a SQL statement has a private
SQL area. Session memory is the memory allocated to hold a session’s
variables (logon information) and other information related to the session.
For a shared server, the session memory is shared and not private.
Not all RAM in Oracle is shared memory. When you start a user process,
that process has a private RAM area, used for sorting SQL results and
managing special joins called ?hash? joins. This private RAM is known as
the Program Global Area (PGA). Each individual PGA memory area is
allocated each time a new user connects to the database.