Process Structure (Oracle) :
Oracle takes an advantage of various types of process :
- User Process : User Process started at the time when a database user requests to make a connection to the Oracle Server
- Server Process : Server Process connects to the Oracle Instance and It is started when a user establishes a session.
- Background Processes : Background Processes started when an Oracle Instance is started
User Process : User process working workflow is as below.
- A program that requests interaction with the Oracle Server
- Must first Establish a connection
- Does not interact Directly with the Oracle Server
A Database user who has need some Information from the database, then it is must to make a connection request to establish a connection with the oracle server. The connection is requested using a database interface tool, such as SQL*Plus, and beginning the user process. The user process does not interact directly with the Oracle Server. Rather it Generates calls through the user program interface (UPI) Which creates a session and starts a server process.
Server Process : User process working workflow is as below.
- A program that directly interacts with the Oracle Server
- Fulfills calls generated and returns result.
- Can be Dedicated or Shared Server
Once a user has established a connection, a server process is started to handle the user processes request. A Server Process Can be either a dedicated server process or a shared server process.
In Dedicated server environment, The Server process handles the request of a single user process. Once a user process disconnects, the server process is terminated.
In a Shared Server environment, the server process handles the request of several User Processes. The server Process communicates with the oracle server using the Oracle Program Interface (OPI).
Background Process : Background Process are Maintains and enforces relationship between Physical structure and Memory structure.
The Oracle architecture has five mandatory background process. In addition to the mandatory background process Oracle has many optional background process that are started when their option is being used.
- Mandatory Background Processes
- DBWn ( Database Writer)
- LGWR (Log Writer )
- PMON (Process Monitor )
- SMON (Syatem Monitor )
- CKPT (Checkpoint)
- Optional Background Processes: Optional background Process are many. Below are the few optional Background processes are as below :
- ARCn (Archiver Process)
- CJQ0 (Coordinator Job Queue background Process)
- Dnnn (Dispatcher)
- LCKn ( RAC lock manager - Instance Locks)
- LMDn (RAC DLM monitor - Remote Locks)
- LMON ( RAC DLM monitor - Global Locks)
- LMS (RAC global cache Service )
- Pnnn ( Parallel Query Slaves )
- QMNn (Advance Queuing)
- RECO ( Recoverer )
- Snnn (Shared Server)
Now we will look here working Capabilities of the mandatory background Processes including one very important optional background Process ARCn (Archiver Process)
Mandatory Background Process:
- DBWn (Database Writer) : DBWn is a mandatory background process which is part of the SGA. It is Started when instance starts. When the server process records any changes to undo and data blocks in the Database Buffer Cache, DBWn Writes the dirty buffers from the database buffer cache to the data files. It Ensures that a sufficient number of free buffers are available in the Database Buffer Cache. Database performance is improved because server processes make changes only in the Database Buffer Cache.
- Free Buffer : Free Buffers are buffer that can be overwritten when server process need to read in blocks form the data files.
DBWn Process writes the dirty buffers to the Data files when the fallowing below Events are Occurs :
- Incremental or Normal Checkpoint
- The number of Dirty Buffers reaches to threshold Value
- A process scans a specified number of Blocks, When Scanning Free Buffers and can not find any
- Timeout Occurs
- A ping request in Real Application Cluster (RAC) environment
- Placing a Normal and temporary tablespace offline
- Placing a tablespace in read-only mode
- Dropping Or Truncating a table
- ALTER TABLESPACE tablespace name BEGIN BACKUP
- LGWR (Log Writer) : LGWR is the mandatory background Process and part of the SGA. It is started when instance starts. LGWR performs sequential writes from the Redo Log Buffer to the online redo log file under the fallowing situations.
- When a transaction commits
- When the Redo Log Buffer is one-third full
- When there is more than 1 MB of Changes recorded in the Redo Log Buffer
- Before DBWn writes modified blocks in the Database Buffer Cache to the Data Files
- Every Three Seconds
Because the redo is needed for recovery, LGWR confirms the commit operation only after the redo is written to disk. LGWR can also call on DBWn to write to the data file.
- SMON (System Monitor ) : SMON is the mandatory background process and part of the SGA. It is started when instance starts. SMON Process has fallowing responsibilities :
- Instance Recovery
- Rolls Forward changes in online redo log files
- Opens database for user access
- Rolls back uncommitted transactions
- Coalesces Free Space
- Deallocates temporary segments
- Rolling Forward to Recover data that has not been recorded in the data files but that has been recorded in the Online Redo Log file. This Data has not been written to disk because of the loss of the SGA during Instance failure. During this process, SMON reads the Online Redo Log Files and applies the changes recorded in the Online Redo Log Files to the data blocks, Because All committed transactions have been written to the Online Redo Log Files. This process Completely recovers these transactions.
- Opening the database so that user can log on. Any data that is not locked by unrecoverable transactions is immediately available,
- Rolling back uncommitted transactions. They are rolled back by SMON or by the individual server process as they access locked data.
- It combines , Or Coalesces , Adjacent areas of free space in the data files.
- It Deallocates temporary segments to return them as free space in data files.
- PMON (Process Monitor) : PMON is the mandatory background process and part of the SGA. It is started when instance starts. PMON process has fallowing Responsibility :
- The background Process PMON Performs Clean up after failed Process By fallowing as below:
- Rolling Back the user's current transactions
- Releasing all currently held tables or Row Locks
- Freeing other resources currently reserves by the users
- Restarts Dead Dispatchers
- CKPT (Checkpoint) : CKPT is the mandatory background process and part of the SGA. It is started when instance starts. It is Responsible for fallowing responsibilities :
- Signaling DBWn at checkpoints
- Updating Data files headers with checkpoint information
- Updating control files with checkpoint Information
Every three Seconds the CKPT process stores data in the control file to identify that place in the online redo log file from where recovery is to begin, which is called a checkpoint.
The purpose of a checkpoint is to ensure that all of the buffers in the Database Buffer Cache that were modified prior to a point in time have been written to the data files. This point in time (Called the checkpoint position) is where database recovery is to begin in the event of an instance failure. DBWn will already have written all of the buffers in the Database Buffer Cache that were modified prior to that point in time.
Prior to Oracle 9i, This was done at the end of the Online Redo Log File. In the Event of a log switch CKPT also writes this checkpoint information's to the headers of the data files.
Checkpoints are initiated for the fallowing Reasons :
- To Ensure that modified data block in memory are written to disk regularly so that data is not lost in case of a system or Database failure.
- To reduce the time required for instance recovery. Only the online redo log file entries following the last checkpoint need to be processed for recovery occurs.
- To Ensure that all committed data has been written to the data files during shut down.
Checkpoint information written by CKPT includes checkpoint Position, System Change Number (SCN), Location in the online redo log file to begin recovery, Information About logs and So on.
- ARCn (Achiever ) Process : ARCn process is an optional background Process but it is very Important process whose play a crucial role to recovering a database after a loss of disk or Disk failures. ARCn process functionalities as below:
- Automatically archives Online Redo Log Files when ARCHIVE LOG mode is enabled.
- Preserves the record of all changes made to the database
ARCn is an optional background process , however, it is crucial to recovering a database after the loss of a disk. As Online Redo Log files get filled, the oracle server begins writing to the next online redo log file. The Process of switching from one Online Redo Log file to another is called a Log Switch.
The ARCn process initiates backing up, or archiving, of the filled log group at every log switch. It automatically archives the online redo log file before the log can be reused, So all of the changes made to the database are preserved. This Enables recovery of the database to the point of failure even if a disk drive is damaged.
Archiving Online Redo Log Files :
One of the important decisions that a Database Admin (DBA) has to make is whether to configure the database to operate in ARCHIVE LOG or in NO ARCHIVE LOG mode.
NO ARCHIVE LOG Mode : In NO ARCHIVE LOG mode, the online redo log files are overwritten each time when a log switch occurs. LGWR does not overwrite an Online Redo Log File group until the checkpoint for the group is complete. This Ensures that the committed data can be recovered if there is an instance crash. During the instance crash, Only SGA is lost. There is no Loss of disks, Only memory. For Example, An operation system crash causes Instance Crash.
ARCHIVE LOG Mode : If the Database configured to run in ARCHIVE LOG mode, Inactive groups of filled Online Redo Log Files must be archives before they can be used again. Because changes made to the database are recorded in the online redo log files, The DBA can use the physical backup of the data files and the archived redo log files to recover the database without losing any committed data because of nay single point of failure, Including the loss of a disk. Usually, a production database is configured to run in ARCHIVE LOG mode.
Thank You !!
Nice.... Content is very usful...
ReplyDelete