Oracle architecture with details-yogiji creations

Oracle Overview and Architecture

Presented By,
Shaunak Mandlik
Sanjay Rahane
Sumedh Ambapkar
www.yogijicreations.com

Index

Brief Overview of Oracle Database and Architecture
Overview of Databases and Instances
 Oracle Logical Storage Structures
Oracle Physical Storage Structures
Oracle Memory Structures
Oracle Background Processes
Example


Oracle Architecture Overview


Oracle Database


Database and Instance

 A database is a collection of data on disk in one or more files on a database server
that collects and maintains related information.
 The database consists of various physical and logical structures. The table is the
most important logical structure having rows and columns.
 A database provides a level of security to prevent unauthorized access to the data.
 Files composing a database fall into two broad categories: database files and non-
database files.
 Database files contain data and metadata; non-database files contain initialization
parameters, logging information, and so forth.
 Instance:
 An Oracle instance is composed of a large block of memory allocated
 in an area called the System Global Area (SGA), along with a number of
background processes that interact between the SGA and the database files on
disk.


Oracle Architecture

 database vs. instance
Database Instance

Parameter files* System Global Area (SGA)
Control files** Background Processes
Data files
Redo Log files

Memory
Disk

* Parameter files include the init<SID>.ora and config<SID>.ora files. These are
used to set options for the database.
** Control files contain information about the db in binary form. They can be
backed up to a text file however.

Oracle Logical Storage Structures

 The data files in an Oracle database are grouped
together into one or more table spaces.

 Within each table space, the logical database
structures are there such as tables and indexes.

 Segments that are further subdivided into extents
and blocks. This logical subdivision of storage allows
Oracle to have more efficient control over disk
space usage.


The Logical Layer

The logical layer of the database
consists of the following
elements:

One or more table spaces.

The database schema, which consists
of items such as
tables, clusters, indexes, views, stored
procedures, database
triggers, sequences, and so on.


Oracle Logical Storage Structures


Block

 A database block is the smallest unit of storage in the Oracle database. The size of
a block is a specific number of bytes of storage within a given table space within
the database.

The default block size is specified by the Oracle initialization parameter
DB_BLOCK_SIZE.

The data block sizes should be a multiple of the operating system's block size
within the maximum limit to avoid unnecessary I/O.

Oracle data blocks are the smallest units of storage that Oracle can use or
allocate.


Data Block Format


Data Block Format

 Header (Common and Variable)
The header contains general block information, such as the block address and the type of
segment (for example, data or index).
 Table Directory
This portion of the data block contains information about the table having rows in this block.
 Row Directory
This portion of the data block contains information about the actual rows in the block (including
addresses for each row piece in the row data area).
 After the space has been allocated in the row directory of a data block's overhead, this space is
not reclaimed when the row is deleted
 Overhead
The data block header, table directory, and row directory are referred to collectively as overhead
 Row Data
This portion of the data block contains table or index data. Rows can span blocks.


PCTFREE, PCTUSED PARAMETERS

 The PCTFREE Parameter
 The PCTFREE parameter sets the minimum percentage of a data
block to be reserved as free space for possible updates to rows that
already exist in that block.

 For example, assume that you specify the following parameter
within a CREATE TABLE statement:
 PCTFREE 20

 This states that 20% of each data block in this table's data segment
be kept free and available for possible updates to the existing rows
already within each block.


PCTUSED PARAMETER

 The PCTUSED parameter sets the minimum percentage of a block that can be used for
row data plus overhead before new rows are added to the block.

 After a data block is filled to the limit determined by PCTFREE, Oracle considers the
block unavailable for the insertion of new rows until the percentage of that block falls
beneath the parameter PCTUSED

 Until this value is achieved, Oracle uses the free space of the data block only for
updates to rows already contained in the data block.

 . For example, assume that you specify the following parameter in a CREATE TABLE
statement:
PCTUSED 40

 In this case, a data block used for this table's data segment is considered unavailable
for the insertion of any new rows until the amount of used space in the block falls to
39% or less


Diagram


Extents
 The extent is the next level of logical grouping in the database.

 An extent consists of one or more
database blocks. When you enlarge a database object, the space added to the object is
allocated as an extent.

When Extents Are Allocated
When you create a table, Oracle allocates to the table's data segment an initial extent of a specified number
of data blocks.

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 greater size than the previously allocated
extent in that segment.


How Extents Are Allocated

 Oracle uses different algorithms to allocate extents,
depending on whether they are locally managed or dictionary
managed.

 With locally managed table spaces, Oracle looks for free
space to allocate to a new extent by first determining a
candidate data file in the table space and then searching the
data file's bitmap for the required number of adjacent free
blocks.

 If that data file does not have enough adjacent free space,
then Oracle looks in another data file.


Extents in Nonclustered Tables

As long as a nonclustered table exists or until we truncate the table, any data
block allocated to its data segment remains allocated for the table.

 After you drop a nonclustered table, this space can be reclaimed when
other extents require free space.

 Oracle reclaims all the extents of the table's data and index segments for
the table spaces that they were in and makes the extents available for
other schema objects in the same table space.

 In dictionary managed table spaces, when a segment requires an extent
larger than the available extents, Oracle identifies and combines
contiguous reclaimed extents to form a larger one. This is called
coalescing extents.


Extents in Clustered Tables

 Clustered tables store information in the data segment created
for the cluster. Therefore, if you drop one table in a cluster, the
data segment remains for the other tables in the cluster, and
no extents are deallocated.

 Extents in Temporary Segments
 When Oracle completes the execution of a statement requiring a
temporary segment, Oracle automatically drops the temporary
segment and returns the extents allocated for that segment to the
associated table space.

 A single sort allocates its own temporary segment in a
temporary table space of the user issuing the statement and
then returns the extents to the table spaces.


Extents in Rollback Segments

 Oracle periodically checks the rollback
segments of the database to see if they have
grown larger than their optimal size.

 If a rollback segment is larger than is optimal
(that is, it has too many extents), then Oracle
automatically deallocates one or more extents
from the rollback segment.


Segments

 The next level of logical grouping in a database is the
segment.
 A segment is a group of extents
that form a database object that Oracle treats as a unit, such
as a table or index

 Four types of segments are found in an Oracle database:
1. data segments
2. index segments
3. temporary segments
4. rollback segments.


Segments

 Data Segment
 Every table in the database resides in a single data segment,
consisting of one or more extents.

 Oracle allocates more than one segment for a table if it is a partitioned
table or a clustered table .

 Oracle creates this data segment when you create the table or cluster
with the CREATE statement.

 The storage parameters for a table or cluster determine how its data
segment's extents are allocated


Index Segment

 Each index is stored in its own index segment. As with partitioned tables.

 Each partition of a partitioned index is stored in its own segment. Included
in this category are LOB index segments.

 Every nonpartitioned index in an Oracle database has a single index
segment to hold all of its data.

 Oracle creates the index segment for an index or an index partition when
you issue the CREATE INDEX statement.

 In this statement, you can specify storage parameters for the extents of the
index segment and a table space in which to create the index segment.


Temporary Segment

 When processing queries, Oracle often requires temporary
workspace for intermediate stages of SQL statement parsing and
execution.

 When a user’s SQL statement needs disk space to complete an
operation, such as a sorting operation that cannot fit in memory,
Oracle allocates a temporary segment.

 Temporary segments exist only for the duration of the SQL
statement.

 Oracle can also allocate temporary segments for temporary tables
and indexes created on temporary tables.


Rollback Segment

 Rollback segment was created to save the previous
values of a database DML operation in case the
transaction was rolled back, and to maintain the
“before” image data to provide read-consistent views of
table data for other users accessing the table.

 Rollback segments were also used during
database recovery for rolling back uncommitted
transactions that were active when the database
instance crashed or terminated unexpectedly.


Oracle Physical Storage Structures

Mainly Consists of :

Other Supportive Files :
Backup Files
Oracle Managed Files
Alert and Trace Log Files


Relationship Between Physical and Logical Storage Structures


Data Files

Oracle database must contain at least one data file
Each data file is a part of tablespace
One tablespace can contain more than one data files
Data file can extend up to any size (depends on disk space)
AUTOEXPAND and MAXSIZE Parameters


Redo Log Files

Stores redo log entries, whenever any DML or DDL operation
happens
Database should contain at least two groups of redo log files
Works in circular fashion
Current redo log file
ACTIVE Status-used for instance recovery
Inactive Status -not used for instance recovery
Used in database recovery


Redo Log Files

Ideally redo log files are never used
Mostly used when power failure occurs or instance is
restarted
Redo log files are always multiplexed


Control Files

Every oracle database must contain at least one control file
Maintains metadata(structure) of the database
Mainly contains :
Name of the database
When the database is created
Location of all data files and redo log files


Control Files

In addition it contains :
Information used by RMAN
Types of backups performed on the database
Every change to the database structure is immediately
reflected in control files
Can be multiplexed
Only one control file is considered as a primary for retrieving
database metadata


Control Files

Backup of control file :
“Alter database backup control file to trace”
command is used
It produces SQL Script that can recreate control
file


Archived Log Files

Oracle database operates on two modes :
1. Archive log mode
2. No archive log mode
 Archived log files are used to prevent the loss of DML as well
as DDL entries written in redo log files
 Helps to retrieve the contains of previous transactions in case
of media failure


Initialization Parameter Files

Used to characterize the instance
Only way to specify the parameters to the oracle instance
One of two types of parameter files :
1. Init<SID>.ora or init.ora or PFILE
2. Spfile<SID>.ora or spfile.ora or SPFILE



 Mainly specifies location for:
 Trace file
 Control files
 Filled redo log files and so forth
 Specifies :
 limits on the sizes of various structures in SGA
 How many users can connect to the database
simultaneously



 Dynamic system parameter :
 Parameters can be changed using “alter system”
command
 DBA must change the init.ora file for effect of change
when instance starts next time
 For running instance spfile change is done automatically
 SPFILE can be backed up


Alert & Trace Log Files

Alert Files
Used for writing routine status messages and error conditions
Example : when the database is started up or shut
down, messages are recorded in alert log file with
initialization parameters
Alert files are also used to record :
Operations on tablespaces like, adding tablespace,deleting
tablespace,adding data file to table space etc.



Error conditions, such as table space running out of space,
corrupted redo log files etc.
Trace Files
Used to write error messages related to instance and
background processes
Entries are written in trace files when
Error occurs in user session
Database connection is refused



Use of Trace Files :
SMON needs to perform instance recovery
PMON needs to perform resource releases when user
process or request fails


Backup Files

Are the copies of oracle database files
Can be generated using :
OS Copy Commands
Oracle RMAN (Recovery Manager)
Backup Files may be :
Data Files Archived Log Files
Control Files SPFILES etc.
Redo Log Files


Oracle Managed Files

Simplifies administration of oracle database
No need of DBA to manage operating system files
Associated with Logical Volume Manager
Oracle internally creates and deletes files needed for
following database structures :
Tablespaces
Online Redo Log Files
Control Files


Password Files

Used to authenticate oracle system administrators
Privileges like SYSDBA and SYSOPER are granted through
password file
Database startup and shutdown operations are authenticated
through password file
Password file is created using “orpwd” command


Oracle Overview And Architecture

Oracle Memory Structure


Memory

What is Memory?
 Memory is ability to store, retain, and recall information.


Memory


Oracle Memory Structure

 Oracle uses the server’s physical memory to hold many things for
an oracle instance like executable code , session information and
lock on database objects.

 In addition memory structure also contains user and data dictionary
SQL Statements , along with cached information that is eventually
permanently stored on disk.
 The data area allocated for an oracle instance is called the System
Global Area (SGA).
 Oracle Executable reside in the software code area
 Program Global Area (PGA) is private to each server and
background process . One PGA is allocated for each process.


System Global Area (SGA)

 A system global area (SGA) is a group of shared memory structures that
contain data and control information for one Oracle database instance.

 If multiple users are concurrently connected to the same instance, then the
data in the instance's SGA is shared among the users. Consequently, the SGA
is sometimes called the shared global area.

 Oracle automatically allocates memory for an SGA when you start an instance,
and the operating system reclaims the memory when you shut down the
instance.

 Each instance has its own SGA. When oracle instance is started memory
allocated for the SGA depends on values specified in initialization parameter
file. If the parameter SGA_MAX_SIZE is specified then the file size should not
exceed more than SGA_MAX_SIZE. If SGA_MAX_SIZE is not specified but
SGA_TARGET is specified then size is automatically adjusted to
SGA_TARGET size which can be changed when instance is running.


SGA
 The SGA is read/write. All users connected to a multiple-process database instance can read information
contained within the instance's SGA, and several processes write to the SGA during execution of Oracle.

The SGA contains the following data structures:
 Database buffer cache.
 Redo log buffer.
 Shared pool .
 Java pool .
 Large pool (optional).
 Data dictionary cache.
 Library Cache.

 Part of the SGA contains general information about the state of the database (Online, offline or recovery)
and the instance, which the background processes need to access this is called the fixed SGA.


Database Buffer Cache
 The database buffer cache is the portion of the SGA that holds copies of data blocks read from
datafiles . It stores most recently used block of data. All the user concurrently connected to
instance share the same date from data buffer.

 The buffers in the cache are organized in two lists: the dirty list and the least recently used (LRU)
list.

 Dirty List :-The dirty list holds dirty buffers, which contain data that has been modified but has not
yet been written to disk.

 LRU List :-The least recently used (LRU) list holds free buffers, pinned buffers, and dirty buffers that
have not yet been moved to the dirty list.

 Free buffer :- Free buffer are the buffers which have not been modified and are available for use.

 Pinned Buffer :- The buffers Which are currently being accessed are called as pinned buffer.


Database Buffer Cache (Conti)

 Dirty buffer :- If the buffer are no longer pinned but contents have changed
and must be flushed to disk by DBWn before it can aged out.

How Buffer cache are Accessed?

 When oracle server process requires a specific data block, it first searches
it in Buffer cache. If it finds required block, it is directly accessed and this
event is known as Cache Hit. If searching in Buffer cache fails then it is
read from datafile on the disk and the event is called Cache Miss. If the
required block is not found in Buffer cache then process needs a free
buffer to read data from disk.
 It starts search for free buffer from least recently used end of LRU list .In
process of searching, if user process finds dirty block in LRU list it shifts
them to Write List. If the process can not find free buffers until certain
amount of time then process signals DBWn process to write dirty buffers to
disks.


Database Buffer Cache (Conti)
 When an Oracle process accesses a buffer, the process moves the buffer to the most
recently used (MRU) end of the LRU list. As more buffers are continually moved to the
MRU end of the LRU list, dirty buffers "age" towards the LRU end of the LRU list.

Size of the Database Buffer Cache.

 Oracle allows different block size for different tablespaces. A standard block size is
defined in DB_BLOCK_SIZE initialization parameter . System tablespace uses standard
block size. DB_CACHE_SIZE parameter is used to define size for Database buffer
cache. For example to create a cache of 800 mb, set parameter as below
DB_CACHE_SIZE=800M

 If you have created a tablesapce with bock size different from standard block size, for
example your standard block size is 4k and you have created a tablespace with 8k
block size then you must create a 8k buffer cache as below.
DB_8K_CACHE_SIZE=256M


Shared Pool

 Shared pool contains two major sub caches.
1)Library cache.
2)Data Dictionary cache.

1)Library cache :- Oracle's library cache , which is responsible
for collecting , parsing , interpreting , and executing all of the
SQL statements that go against the Oracle database. Library
cache also holds information about PL/SQL Statement.

Library cache consists of Shared SQL Area , PL/SQL Area .


Shared Pool(Cont)

Shared SQL Area

 A shared SQL area contains the parse tree and execution plan for a given
SQL statement. Oracle saves memory by using one shared SQL area for SQL
statements run multiple times, which often happens when many users run the
same application.

 Oracle allocates memory from the shared pool when a new SQL statement is
parsed, to store in the shared SQL area. The size of this memory depends on
the complexity of the statement.

 If the entire shared pool has already been allocated, Oracle can deallocate
items from the pool using a modified LRU (least recently used) algorithm until
there is enough free space for the new statement's shared SQL area. If Oracle
deallocates a shared SQL area, the associated SQL statement must be
reparsed and reassigned to another shared SQL area at its next execution.


Shared Pool(cont)

PL/SQL Area

o Oracle processes PL/SQL program units (procedures, functions, packages,
anonymous blocks, and database triggers) much the same way it
processes individual SQL statements. Oracle allocates a shared area to
hold the parsed, compiled form of a program unit.

o Oracle allocates a private area to hold values specific to the session that
runs the program unit, including local, global, and package variables (also
known as package instantiation) and buffers for executing SQL.

o If more than one user runs the same program unit, then a single, shared
area is used by all users, while each user maintains a separate copy of his
or her private SQL area, holding values specific to his or her session.


Shared Pool(cont)

Data Dictionary cache

o The data dictionary is collection of database tables, owned by the SYS and
SYSTEM schemas that contain the metadata about database, its
structures, and the privileges and roles of database user. The data
dictionary cache holds cached blocks from the data dictionary tables.

o The data dictionary is also known as “row cache”. It is known as row cache
as it holds data in rows instead of Buffer. It is used to cache data dictionary
related information in RAM for quick access. The dictionary cache is like
the buffer cache, except it’s for Oracle data dictionary information instead
of user information.

o If the data dictionary cache is too small, request for information from the
data dictionary will cause extra I/O to occur these I/O bound data dictionary
request are called recursive calls and should be avoided.


Redo Log Buffer

 The redo log buffer holds the most recent changes to data block in detafiles. When the
redo log buffer is one-third full, or every three seconds, redo log record are written to
redo log files.

 The redo log buffer is a RAM area (defined by the initialization parameter log_buffer)
that works to save changes to data, in case something fails and Oracle has to put it
back into its original state (a “rollback”).
 When Oracle SQL updates a table (a process called Data Manipulation Language, or
DML), redo images are created and stored in the redo log buffer. Since RAM is faster
than disk, this makes the storage of redo very fast.

The Oracle redo log buffer provides the following functions within the Oracle SGA:
 Serves for assistance with database recovery tasks
 Records all changes made to database blocks
 Places changes recorded to redo entries for redo logs


Redo Log Buffer(cont)

 Oracle will eventually flush the redo log buffer to disk. This can
happen in a number of special cases, but what’s really important is
that Oracle guarantees that the redo log buffer will be flushed to
disk after a commit operation occurs. When you make changes in
the database you must commit them to make them permanent and
visible to other users.

Size Of Redo Log Buffer
 The initialization parameter LOG_BUFFER determines the size (in
bytes) of the redo log buffer. In general, larger values reduce log file
I/O, particularly if transactions are long or numerous. The default
setting is either 512 kilobytes (KB) or 128 KB times the setting of
the CPU_COUNT parameter, whichever is greater.


Large Pool

 The large pool is an optional area of SGA .As name implies the
large pool makes available large blocks of memory for operations
that need to allocate large blocks of memory at a time. It is used for
transaction that interacts with more than one database ,message
buffer for processes performing parallel queries and RMAN parallel
backup and restore operations.

 The memory for Oracle 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.


Java Pool

Java Pool
 The java pool is used by oracle JVM for all java code and data
within a user session. Storing java code an data in java pool is
similar to that of SQL and Pl/SQL code cached in shared pool.

 Java Pool consist of Compile code of java


Stream Pool

 In a single database, you can specify that Streams memory be allocated
from a pool in the SGA called the Streams pool.

 To configure the Streams pool, specify the size of the pool in bytes using
the STREAMS_POOL_SIZE initialization parameter.

 If the size of the Streams pool is greater than zero, then any SGA memory
used by Streams is allocated from the Streams pool. If the size of the
Streams pool is zero, then the memory used by Streams is allocated from
the shared pool and may use up to 10% of the shared pool.

 If a Streams pool is not defined, then one is created automatically when
Streams is first used.


Program Global Area (PGA)
 The program global area is an area of memory allocated and private for one process.

 The configuration of PGA depends on Connection configuration of the oracle database
it can either shared server or dedicated server.

Shared Server
o In Shared Server multiple user share connection to database , minimizing memory
usage on the server , but potentially affecting response time of user request.

o In shared server environment SGA hold session information for a user instead of PGA.

o Shared Server environment is generally used for large Simultaneous connection to
database with infrequent or short-lived request


PGA (cont)

Dedicated Server
o In a dedicated server environment each user process gets its own connection
to database the PGA contains the session memory for this configuration.

Sort , Hash, Merge Area
o The PGA also includes a sort area . The sort area is used whenever user
request requires sort , bitmap merge , or hash join operations.

Initialization parameter
o PGA_AGGREGATE_TARGET parameter , and WORKAREA_SIZE_POLICY
initialization parameter , can ease system administration by allowing the DBA
to choose a total size for work areas and let oracle manage and allocate the
memory between all user process.


Software Code Area

o Software code areas are portions of memory used to store code
that is being run or can be run. Oracle code is stored in a software
area that is typically at a different location from users' programs a
more exclusive or protected location.

o Software areas are usually static in size, changing only when
software is updated or reinstalled. The required size of these areas
varies by operating system.

o Software areas are read only and can be installed shared or non-
shared. When possible, Oracle code is shared so that all Oracle
users can access it without having multiple copies in memory. This
results in a saving of real main memory and improves overall
performance.


Background Processes


Database Writer


Database Writer Process (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.

 When a buffer in the database buffer cache is modified, it is marked dirty.

 A cold buffer is a buffer that has not been recently used according to the least recently
used (LRU) algorithm.

 The DBWn process writes cold, dirty buffers to disk so that user processes are able to
find cold, clean buffers that can be used to read new blocks into the cache.

 By writing cold, dirty buffers to disk, DBWn improves the performance of finding free
buffers while keeping recently used buffers resident in memory.


Database Writer Process (DBWn)

 The initialization parameter DB_WRITER_PROCESSES specifies the number of DBWn processes.

 The maximum number of DBWn processes is 20.

 If it is not specified by the user during startup, Oracle determines how to set DB_WRITER_PROCESSES
based on the number of CPUs and processor groups.

 The DBWn process writes dirty buffers to disk under the following conditions:

 When a server process cannot find a clean reusable buffer after scanning a threshold number of buffers, it
signals DBWn to write. DBWn writes dirty buffers to disk asynchronously while performing other processing.

 DBWn periodically writes buffers to advance the checkpoint, which is the position in the redo thread (log)
from which instance recovery begins. This log position is determined by the oldest dirty buffer in the buffer
cache.


Log Writer (LGWR)


Log Writer Process (LGWR)

 The log writer process (LGWR) is responsible for redo log buffer management.

 LGWR writes all redo entries that have been copied into the buffer since the last
time it wrote.

 LGWR writes one contiguous portion of the buffer to disk.

 LGWR writes:
 A commit record when a user process commits a transaction.
 Redo log buffers
 Every three seconds
 When the redo log buffer is one-third full
 When a DBWn process writes modified buffers to disk, if necessary


Log Writer Process (LGWR)

 When a user issues a COMMIT statement, LGWR puts a commit record in
the redo log buffer and writes it to disk immediately, along with the
transaction's redo entries.
 In times of high activity, LGWR can write to the redo log file using group
commits.
 For example, assume that a user commits a transaction.
 LGWR must write the transaction's redo entries to disk, and as this
happens, other users issue COMMIT statements.
 However, LGWR cannot write to the redo log file to commit these
transactions until it has completed its previous write operation.
 After the first transaction's entries are written to the redo log file, the entire
list of redo entries of waiting transactions (not yet committed) can be
written to disk in one operation, requiring less I/O than do transaction
entries handled individually.


CKPT


Checkpoint Process (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.

 The statistic DBWR checkpoints displayed by the
System_Statistics monitor in Enterprise Manager
indicates the number of checkpoint requests completed.


System Monitor


System Monitor Process (SMON)

 The system monitor process (SMON) performs 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 table spaces.

 If any terminated transactions were skipped during instance
recovery because of file-read or offline errors, SMON recovers them
when the table space or file is brought back online.

 With Real Application Clusters, the SMON process of one instance
can perform instance recovery for a failed CPU or instance.


Process Monitor


Process Monitor Process (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 stopped running (but not any that Oracle has terminated
intentionally).

 PMON also registers information about the instance and dispatcher processes with
the network listener.


Archiver(ARCn)


Archiver Processes (ARCn)

 The archiver process (ARCn) copies 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.

 The archiver process (ARCn) copies redo log files to a designated storage device after a log
switch has occurred.

 The LGWR process starts a new ARCn process whenever the current number of ARCn
processes is insufficient to handle the workload.

 We can specify multiple archiver processes with the initialization parameter
LOG_ARCHIVE_MAX_PROCESSES.

 The default value of this parameter is 1.


Queue Monitor Processes (QMNn)

 The queue monitor process is an optional background
process for Oracle Streams Advanced Queuing, which
monitors the message queues.

 You can configure up to 10 queue monitor processes.

 These processes, like the job queue processes, are
different from other Oracle background processes in that
process failure does not cause the instance to fail.


Other Background Processes

 There are several other background processes that might be
running. These can include the following:

 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 which have been recently
modified


Query Execution

 Assume a user (working with SQL *Plus) issues an update
statement on the table TAB such that more than one tuple is
affected by the update . The statement is passed to server by
USER process . Then the Server(or rather the query processor)
checks whether this statement is already contained in the library
cache such that the corresponding information (parse tree ,
execution plan) can be used .If the statement can not be found , it
is parsed and after verifying the statement (user privileges , affected
tables and columns) using data from the dictionary cache , a query
execution plan is generated by the query optimizer . Together with
parse tree , this plan is stored in the library cache .

 For the object affected by the statement (here the table TAB) it is
checked , whether the corresponding data blocks already exist in
the database buffer .If not the USER proceed reads the data blocks
into the database buffer .If there is not enough space in the buffer ,
the last recently used blocks of other objects are written back to the
disk by the DBWR process.


Query Execution

 The modifications of the tuples affected by the update occurs in the
database buffer .Before the data blocks are modified , the “before
image” of the tuples is written to the rollback segments by the
DBWR process.

 While the redo-log buffer is filled during the data block modifications
, the LGWR process writes entries from the redo-log buffer to redo-
log files.

 After all tuples(or rather the corresponding data blocks) have been
modified in the database buffer , the modification can be commited
by the user using the commit command.


Query Execution

 As long as no commit ha been issued by user , modifications can be
undone using the rollback statement . In this case , the modified
data blocks in the database buffer are overwritten by the original
blocks stored in the rollback segments.

 If the user issues a Commit ,the space allocated for the blocks in
the rollback segments is de-allocated and can be used by other
transactions . Furthermore, the modified blocks in the database
buffer are unlocked such that other users now can read the
modified blocks

 The end of Transaction (more precisely the Commit) is recorded in
the redo-log files. The modified blocks are only written to the disk
by the DBWR process if the space allocated for the blocks is
needed for other blocks.


Transaction Example - Update

UPDATE table
SET user = ‘SHIPERT’
WHERE id = 12345



1 ROW UPDATED



COMMIT



COMMIT
SUCCESSFUL


www.yogijicreations.com For queries: info@yogijicreations.com

Oracle architecture with details-yogiji creations

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Oracle architecture with details-yogiji creations

Similar a Oracle architecture with details-yogiji creations (20)

Último

Último (20)

Oracle architecture with details-yogiji creations