Oracle Background Process

Oracle

SMON: The System Monitor

SMON is the process that gets to do all of the system-level jobs. Whereas PMON was interested in individual processes, SMON takes a system-level perspective of things and is a sort of garbage collector for the database. Some of the jobs it does include the following:

Cleans up temporary space: With the advent of true temporary tablespaces, the chore of cleaning up temporary space has lessened, but it has not gone away. For example, when building an index, the extents allocated for the index during the creation are marked as TEMPORARY. If the CREATE INDEX session is aborted for some reason, SMON is responsible for cleaning them up. Other operations create temporary extents that SMON would be responsible for as well.

Coalesces free space: If you are using dictionary-managed tablespaces, SMON is responsible for taking extents that are free in a tablespace and contiguous with respect to each other and coalescing them into one larger free extent. This occurs only on dictionary-managed tablespaces with a default storage clause that has pctincrease set to a nonzero value.

Recovers transactions active against unavailable files: This is similar to its role during database startup. Here, SMON recovers failed transactions that were skipped during instance/crash recovery due to a file(s) not being available to recover. For example, the file may have been on a disk that was unavailable or not mounted.When the file does become available, SMON will recover it.

Performs instance recovery of a failed node in RAC: In an Oracle RAC configuration,when a database instance in the cluster fails (e.g., the machine the instance was executing on fails), some other node in the cluster will open that failed instanceís redo log files and perform a recovery of all data for that failed instance.

Cleans up OBJ$: OBJ$ is a low-level data dictionary table that contains an entry for almost every object (table, index, trigger, view, and so on) in the database. Many times, there are entries in here that represent deleted objects, or objects that represent ìnot thereî objects, used in Oracleís dependency mechanism. SMON is the process that removes these rows that are no longer needed.

Shrinks undo segments: SMON will perform the automatic shrinking of a rollback segment to its optimal size, if it is set.

Offlines rollback segments: It is possible for the DBA to offline, or make unavailable, a rollback segment that has active transactions. It may be possible that active transactions are using this offlined rollback segment. In this case, the rollback is not really offlined; it is marked as ìpending offline.î In the background, SMON will periodically try to truly take it offline, until it succeeds.

DBWn: Database Writer

The DB Writer is responsible for writing dirty blocks to disk. DBWn will write dirty blocks from the buffer cache , usually to make room in the cache or to advance a checkpoint.Performance of DBWn can be crucial. If it is does not write out blocks fast enough to free buffers for us , we will see both the number and duration of waits on Free Buffer Waits and Write Complete Waits starts to grow.

We can configure more than one DBWn , if fact we can configure up to 36 DBWn.Optimally, the DBWn uses asynchronous I/O to write blocks to disk.With a asynchronous input output .DBWn gathers up a batch of blocks out;rather it goes back and collects the next batch to be written.As the operating system completes the writes, it asynchronously notifies DBWn that it completed the writes.This allows DBWn to work much faster than if it had to do everything serially.

DBWR is slower than LGWR!!

Database writer by definition writes out blocks scattered all over disk ñ DBWR does lots of scattered writes.When you do an update,you will be modifying index blocks that are stored here and there , and data blocks that are randomly distributed on the disk.LGWR on the other hand does a lot of sequential writes to the redo log this is an important distinction and one of the main reasons that Oracle has a redo log and the LGWR process as well as DBWn Process.Scattered writes are significantly slower than the sequential writes.

write-ahead protocol

Before DBWn can write a modified buffer, all redo records associated with the changes to the buffer must be written to disk (the write-ahead protocol). If DBWn finds that some redo records have not been written, it signals LGWR to write the redo records to disk and waits for LGWR to complete writing the redo log buffer before it can write out the data buffers.
How DBWn Works:

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. As buffers are dirtied by user processes, the number of free buffers diminishes. If the number of free buffers drops too low, user processes that must read blocks from disk into the cache are not able to find free buffers. DBWn manages the buffer cache so that user processes can always find free buffers.By writing cold, dirty buffers to disk, DBWn improves the performance of finding free buffers while keeping recently used buffers resident in memory. For example, blocks that are part of frequently accessed small tables or indexes are kept in the cache so that they do not need to be read in again from disk. The LRU algorithm keeps more frequently accessed blocks in the buffer cache so that when a buffer is written to disk, it is unlikely to contain data that will be useful soon.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_BLOCK_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.In all cases, DBWn performs batched (multiblock) writes to improve efficiency. The number of blocks written in a multiblock write varies by operating system.

LGWR : THE LOG WRITER PROCESS

The LGWR process is responsible for flushing to disk the contents of the redo log buffer located in the SGA. It does this when one of the following is true:
Every three seconds
Whenever a commit is issued by any transaction
When the redo log buffer is one-third full or contains 1MB of buffered data
For these reasons, having an enormous (hundred and thousand megabytes) of redo log buffer is not practical; Oracle will never be able to use it all since it pretty much continuously flushes it.

What is the need of redo log files or LGWR?
The logs are written to with sequential writes as compared to the scattered I/O DBWn must perform .Doing large batch writes like this is much more efficient than doing many scattered writes to various parts of a file. This is one of the main reasons for having a LGWR and redo logs in the first place. The efficiency in just writing out the changed bytes using sequential Input-output outweighs the additional input-output incurred. Oracle could just write database blocks directly to disk when you commit, but that would entail a lot of scattered input-output of full blocks, and this would be significant slower than letting LGWR write the changes out sequentially.

PMON : THE PROCESS MONITOR

1.PMON is responsible for cleaning up after abnormally terminated connections.

What If your dedicated server ìfailsî or killed for some reason ?? PMON is the process responsible for fixing and releasing your resources.PMON will perform the below steps :
Initiate rollback of uncommitted work
Release locks
Free SGA resources allocated to the failed process
2.PMON is responsible for monitoring other background processes and restarting them if necessary.
What if a shared server or a dispatcher fails ?? PMON is the solution it will step in and restart another dispatcher.
What if LGWR or DBWR fails ?? In this case PMON will terminate the instance as LGWR and DBWR are very critical background processes.So PMON will terminate the instance and let normal recovery fix the data.

  1. PMON registers the instance with the Oracle TNS Listener: When an instance starts up,the PMON process polls for the well known port address 1521,unless directed otherwise,to check whether or not a listener is up and running.
    What if listener is running but not on port 1521: In this case mechanism is same , except that listener address needs to be explicitly specified by the LOCAL_LISTENER parameter setting.
    What if listener is not started: PMON will periodicall attempts to contact it to register itself.
    What if listener is started:If the listener is running when database is started ,PMON communicates with the listener and passes to it relevant parameters,such as the service name and load metrics of the instance.