Master Note: Database System Monitor Process (SMON) (Doc ID 1495163.1)
In this Document
| Purpose |
| Scope |
| Details |
| Concepts |
| Instance Recovery |
| When Oracle Database Performs Instance Recovery |
| Instance Recovery Phases |
| Cache Recovery |
| Transaction Recovery |
| Temporary Segment Cleanup |
| When does SMON cleanup temporary segments? |
| Temporary Segments in a Permanent Tablespace |
| Temporary Segments in a Temporary Tablespace |
| How to identify whether SMON is cleaning up temporary extents ? |
| Effects on Database |
| Avoidance |
| Force Temp Segment cleanup |
| Free Space COALESCE |
| Effects: |
APPLIES TO:
Oracle Database - Enterprise Edition - Version 9.2.0.8 and laterInformation in this document applies to any platform.
PURPOSE
To have an overview of SMON process and its functions
SCOPE
Applies to Non RAC environment
DETAILS
Concepts
The System Monitor Process (SMON) is the most critical background process for Oracle Database.It performs critical tasks such as instance recovery,dead transaction recovery and maintenance tasks such as temporary space reclamation, data dictionary cleanup, and undo tablespace management.
SMON performs many database maintenance tasks, including the following:
- Creates and manages the temporary tablespace metadata
- Reclaims space used by orphaned temporary segments
- Maintains the undo tablespace by onlining, offlining, and shrinking the undo segments based on undo space usage statistics
- Cleans up the data dictionary when it is in a transient and inconsistent state
- Maintains the SCN to time mapping table used to support Oracle Flashback features
- In an Oracle RAC database, the SMON process of one instance can perform instance recovery for other instances that have failed.
SMON checks regularly to see whether it is needed. Other processes can call SMON if they detect a need for it.
Instance Recovery
Instance recovery ensures that the database is in a consistent state after an instance failure.If an instance of an open database fails, either because of a SHUTDOWN ABORT statement or abnormal termination, then the following situations can result:
- Data blocks committed by a transaction are not written to the data files and appear only in the online redo log. These changes must be reapplied to the database.
- The data files contains changes that had not been committed when the instance failed. These changes must be rolled back to ensure transactional consistency.
Instance recovery uses only online redo log files and current online data files to synchronize the data files and ensure that they are consistent.
When Oracle Database Performs Instance Recovery
Whether instance recovery is required depends on the state of the redo threads. A redo thread is marked open in the control file when a database instance opens in read/write mode, and is marked closed when the instance is shut down consistently. If redo threads are marked open in the control file, but no live instances hold the thread enqueues corresponding to these threads, then the database requires instance recovery.
Oracle Database performs instance recovery automatically in the following situations:
-
The database opens for the first time after the failure of a single-instance database or all instances of an Oracle RAC database. This form of instance recovery is also called crash recovery. Oracle Database recovers the online redo threads of the terminated instances together.
-
Some but not all instances of an Oracle RAC database fail. Instance recovery is performed automatically by a surviving instance in the configuration.
The SMON background process performs instance recovery, applying online redo automatically. No user intervention is required.
Instance Recovery Phases
Cache Recovery
The first phase of instance recovery is called cache recovery or rolling forward, and involves reapplying all of the changes recorded in the online redo log to the data files. Because rollback data is recorded in the online redo log, rolling forward also regenerates the corresponding undo segments.
Rolling forward proceeds through as many online redo log files as necessary to bring the database forward in time. After rolling forward, the data blocks contain all committed changes recorded in the online redo log files. These files could also contain uncommitted changes that were either saved to the data files before the failure, or were recorded in the online redo log and introduced during cache recovery.
Transaction Recovery
After the roll forward, any changes that were not committed must be undone. Oracle Database uses the checkpoint position, which guarantees that every committed change with an SCN lower than the checkpoint SCN is saved on disk. Oracle Database applies undo blocks to roll back uncommitted changes in data blocks that were written before the failure or introduced during cache recovery. This phase is called rolling back or transaction recovery.
Fig 1: Basic Instance Recovery Steps: Rolling Forward and Rolling Back
Oracle® Database Concepts 11g Release 2 (11.2)
Part Number E25789-01
http://docs.oracle.com/cd/E11882_01/server.112/e25789/startup.htm#CEGCHJGF
Temporary Segment Cleanup
Oracle Database often requires temporary workspace for intermediate stages of SQL statement execution. Typical operations that may require a temporary segment include sorting, hashing, and merging bitmaps. While creating an index, Oracle Database also places index segments into temporary segments and then converts them into permanent segments when the index is complete.
Oracle Database does not create a temporary segment if an operation can be performed in memory. However, if memory use is not possible, then the database automatically allocates a temporary segment on disk.
Temporary segments will also be created for the following operations a well.
- CREATE TABLE AS SELECT
- ALTER INDEX REBUILD
- DROP TABLE
- CREATE SNAPSHOT
- CREATE PARTITION TABLE
When does SMON cleanup temporary segments?
During normal operations, user processes that create temporary segments are responsible for cleanup. If the user process dies before cleaning them up, or the user process receives an error causing the statement to fail, SMON is posted to do the cleanup.
- Sort segments residing in PERMANENT tablespace are cleaned up by SMON after the sort is completed.
- For performance issues, extents in TEMPORARY tablespaces are not released or deallocated once the operation is complete. Instead, the extent is simply marked as available for the next sort operation. SMON cleans up the segments at startup.
Temporary Segments in a Permanent Tablespace
The background process System Monitor (SMON) frees the temporary segments when the statement has been completed.If a large number of sort segments has been created, then SMON may take some time to drop them; this process automatically implies a loss of overall database performance.After SMON has freed up the temporary segment, the space is released for use by other objects.
Temporary Segments in a Temporary Tablespace
The background process SMON actually de-allocates the sort segment after the instance has been started and the database has been opened. Thus, after the database has been opened, SMON may be seen to consume large amounts of CPU as it first de-allocates the (extents from the) temporary segment, and after that performs free space coalescing of the free extents created by the temporary segment cleanup. This behavior will be exaggerated if the temporary tablespace, in which the sort segment resides, has inappropriate (small) default NEXT storage parameters.
How to identify whether SMON is cleaning up temporary extents ?
Check whether there are a large number of temporary extents that might be being cleaned up by running the following query a few times
If the count returned by the above query is dropping while SMON is working, it is likely that SMON is performing temp segment cleanup.
Effects on Database
- SMON will continually acquire and then release the ST enqueue in exclusive mode. This can cause contention with other processes and lead to <oerr:ORA-1575> errors.
- It should be noted that a normal/immediate shutdown will not complete until all temporary segments have been cleaned up. Shutdown will 'kick' SMON to complete cleanup.
- If you are using TEMPORARY type temporary tablespaces then SMONs cleanup of the segment can be a problem as it will not service sort segment requests while performing cleanup.
- If SMON is busy cleaning up a TEMP segment containing a lot of extents it cannot service 'sort segment requests' from other sessions. Pointing the users at a PERMANENT tablespace as their temporary tablespace can help keep the system running until SMON is free again.
- Starting with Oracle8i, rather than reverting back to a PERMANENT tablespace if SMON is cleaning up an old sort segment at startup, you can potentially drop and recreate the tempfiles of the existing TEMPORARY tablespace. The cleanup should be faster anyway since by rule a TEMPORARY tablespace made of tempfiles need to be LOCALLY MANAGED.You can remove tempfiles from TEMPORARY tablespaces and keep the logical structure empty.
Avoidance
- Do not create temporary tablespaces with small initial and next default storage parameters.
- Use tablespaces of type TEMPORARY. Sort segments in these tablespaces are not cleaned up. This reduces contention on ST enqueue and also reduces CPU usage by SMON **UNLESS** the database is shutdown and restarted.
- Beware of creating large objects with inappropriate (small) extents. If the creation of the object fails, SMON cleans up. Also, dropping such an object will create a lot of cleanup work for the user process.
Force Temp Segment cleanup
DROP_SEGMENTS event could be set set to force the cleanup of temporary segments.
This routine does what SMON does in the background, i.e. drops temporary segments. It is provided as a manual intervention tool which the user may invoke if SMON misses the post and does not get to clean the temp segments for another 2 hours.
level - tablespace number+1. If the value is 2147483647 then temp segments in ALL tablespaces are dropped, otherwise, only
segments in a tablespace whose number is equal to the LEVEL specification are dropped.
alter session set events 'immediate trace name DROP_SEGMENTS level TS#+1';ion are dropped.
If ts# is 5, an example of dropping the temporary segments in that tablespace would be:
alter session set events 'immediate trace name DROP_SEGMENTS level 6';
Note 177334.1 Overview of Temporary Segments
Note 35513.1 Removing 'Stray' TEMPORARY Segments
Note 61997.1 SMON - Temporary Segment Cleanup and Free Space Coalescing
NOTE:160426.1 - TEMPORARY Tablespaces : Tempfiles or Datafiles ?
Note 102339.1 Temporary Segments: What Happens When a Sort Occurs
Note 1039341.6 Temporary Segments Are Not Being De-Allocated After a Sort
Note 68836.1 How To Efficiently Drop (or Truncate) A Table With Many Extents
Note 47400.1 EVENT: DROP_SEGMENTS - Forcing cleanup of TEMPORARY segments
Note 132913.1 How To Free Temporary Segment in Temporary Tablespace Dynamically
Free Space COALESCE
A free extent in a dictionary-managed tablespace is made up of a collection of contiguous free blocks. When new extents are allocated to a tablespace segment, the database uses the free extent which is closest in size to the required extent.When the segments are dropped,their extents are deallocated and marked a free. It is not combined with adjacent free extents to form a larger free extents.The result is fragmentation that makesallocation of larger extents more difficult.
Fragmentation is addressed such that
- When attempting to allocate a new extent for a segment, the database first tries to find a free extent large enough for the new extent.Whenever the database cannot find a free extent that is large enough for the new extent, it coalesces adjacent free extents in the tablespace and looks again.
The SMON background process periodically coalesces neighboring free extents when the PCTINCREASE value for a tablespace is not zero.
Oracle Database automatically and transparently coalesces the free space of a data block only when the following conditions are true:
- An INSERT or UPDATE statement attempts to use a block that contains sufficient free space to contain a new row piece.
- The free space is fragmented so that the row piece cannot be inserted in a contiguous section of the block.
After coalescing, the amount of free space is identical to the amount before the operation, but the space is now contiguous.
Fig 2: Datablock before and after the Coalesce
If you set PCTINCREASE=0, no coalescing of free extents occurs. If you are concerned about the overhead of ongoing coalesce operations of SMON, an alternative is to set PCTINCREASE=0, and periodically coalesce free space manually.
Manually Coalesce any adjacent free extens user this command:
SMON wakes itself every 5 minutes and checks for tablespaces with default pctincrease != 0.
If the count returned is dropping while SMON is working, it is likely that SMON is coalescing free space.
Effects:
- Because SMON acquires the Space Transaction (ST) enqueue in exclusive mode, other processes requiring the enqueue will be blocked.
- THE DATABASE CAN BE SHUTDOWN CLEANLY WITH UN-COALESCED EXTENTS. If SMON is performing the coalesce, a shutdown will NOT undo the work completed so far.
- Use the 'alter tablespace <tbs name> coalesce' command. This is quicker than SMON, and the work is performed in in fewer space transactions, and therefore makes fewer enqeueue acquisitions. HOWEVER, IF THE COMMAND IS INTERRUPTED, ALL ITS COALESCING WORK WILL BE LOST.
- Offlining the tablespace/datafiles containing the extents to be coalesced has NO effect.
Note 105120.1 Advantages of Using Locally Managed vs Dictionary Managed Tablespaces