Oracle architecture with details-yogiji creations

www.yogijicreations.com

Oracle Overview and Architecture

Presented By,Shaunak MandlikSanjay RahaneSumedh Ambapkar


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


SGA

Request Response

Shared SQLPool Database Buffer Cache

Redo log Buffer

Database Files Redo Log Files

DedicatedServer

UserProcess

DBWR LGWR ARCn

PMONSMONCKPT



SGA

Request Response

Shared SQLPool Database Buffer Cache

Redo log Buffer


UserProcess

DBWR LGWR ARCn

PMONSMON

DedicatedServerDedicated

ServerSharedServers

UserProcessUser

ProcessUserProcessUser

Process

Dispatcher

CKPT



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

Parameter files*Control files**

Data filesRedo Log files

System Global Area (SGA)Background Processes

DiskMemory

Database Instance

* 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.




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.


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.

Block

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


Backup of control file :

“Alter database backup control file to trace”

command is used

It produces SQL Script that can recreate control

file

Control Files


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

Control Files

Redo Log Files

Archived Log Files

SPFILES etc.


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 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


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.


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


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.


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.

Large 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

Java Pool


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

SGA

DatabaseBufferCache

Shared Pool

RedoLogBuffer


DedicatedServer

UserProcess

DBWR LGWR

PMONSMONCKPT

RollbackSegment

1

2

UPDATE tableSET user = ‘SHIPERT’WHERE id = 12345



SGA

DatabaseBufferCache

Shared Pool

RedoLogBuffer


DedicatedServer

UserProcess

DBWR LGWR

PMONSMONCKPT

RollbackSegment

3



SGA

DatabaseBufferCache

Shared Pool

RedoLogBuffer


DedicatedServer

UserProcess

DBWR LGWR

PMONSMONCKPT

RollbackSegment

4



SGA

DatabaseBufferCache

Shared Pool

RedoLogBuffer


DedicatedServer

UserProcess

DBWR LGWR

PMONSMONCKPT

RollbackSegment

5



SGA

DatabaseBufferCache

Shared Pool

RedoLogBuffer


DedicatedServer

UserProcess

DBWR LGWR

PMONSMONCKPT

RollbackSegment

6



SGA

DatabaseBufferCache

Shared Pool

RedoLogBuffer


DedicatedServer

UserProcess

DBWR LGWR

PMONSMONCKPT

RollbackSegment

7



SGA

DatabaseBufferCache

Shared Pool

RedoLogBuffer


DedicatedServer

UserProcess

DBWR LGWR

PMONSMONCKPT

RollbackSegment

81 ROW UPDATED



SGA

DatabaseBufferCache

Shared Pool

RedoLogBuffer


DedicatedServer

UserProcess

DBWR LGWR

PMONSMONCKPT

RollbackSegment

109COMMIT



SGA

DatabaseBufferCache

Shared Pool

RedoLogBuffer


DedicatedServer

UserProcess

DBWR LGWR

PMONSMONCKPT

RollbackSegment

11COMMITSUCCESSFUL



SGA

DatabaseBufferCache

Shared Pool

RedoLogBuffer


DBWR LGWR

PMONSMONCKPT

RollbackSegment

12

www.yogijicreations.com For queries: [email protected]

Oracle architecture with details-yogiji creations

Technology

Transcript of Oracle architecture with details-yogiji creations