Oracle Background Processes - System Monitor (SMON)

-

Oracle Background Processes - System Monitor (SMON) : 

 SMON stands for system monitor process 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.
  1. It is a mandatory background process for running an Oracle instance.
  2. It is the heart of oracle architecture.It performs all system monitoring functions on the oracle database, SMON checks regularly to see whether it is needed. Other processes can call SMON if they detect a need for it.
  3. It checks the space of SYSTEM tablepace and if it is running short of it displays an error message.
  4. SMON wakes up periodicaly to perform housekeeping activities like cleanup of temporary segments that are no longer needed. 
  5. It also coalesces contiguous free extents in dictionary managed tablespaces that have PCTINCREASE set to a non-zero value.
  6. It also removes the unwanted data from UNDO which is committed and passed the time interval specified by UNDO_RETENTION parameter.
  7. It Maintains the SCN to time mapping table used to support Oracle Flashback features.
  8. If the database is crashed (power failure) and next time when we restart the database SMON observes that last time the database was not shutdown gracefully. Hence it requires some recovery, which is known as INSTANCE CRASH RECOVERY.  SMON performs the instance crash recovery before the database is completely open by doing rollforward & rollback of trancations : 
    • If it finds any transaction committed but not found in the datafiles, will now be applies all changes from redolog files to datafiles (rollforward).
    • If SMON observes some uncommitted transaction which has already updated the table in the datafile, is going to be treated as a in doubt transaction and will be rolled back with the help of before image available in rollback segments (rollback).
  9. In RAC, the SMON process of one instance can perform instance recovery for a failed CPU or instance as well.
  10. To view its running, grep it on Linux: ps -ef | grep smon

 For more details refer : (Doc ID 1495163.1)

Comments

Post a Comment

Popular posts from this blog

Guarantee Restore Point Primary-Standby Environment

-
Guarantee Restore Point Primary-Standby Environment: When we have a Data Guard environment (Primary RAC and Standby Standalone Databases) and we want to make use of restore points. We need to follow below steps. Always create a restore point on the standby database first then in Primary. The main reason for this is because the SCN of the standby must be less than the SCN of the primary in case you need to flashback your database. If we didn’t follow the step 1 then we need to rebuild the standby. 1.) Stop Managed Recovery on the Standby Database using SQL*PLUS or Data Guard Broker. $ dgmgrl sys/<Password>@<PRIM/STDBY> DGMGRL>  show database ' STDBY '; edit database 'STDBY' set state = 'APPLY-OFF'; show database ' STDBY ';   OR STDBY.SYS.SQL> select inst_id, process, status, thread#, sequence#, block#, blocks from gv$managed_standby order by inst_id; alter database recover managed standby database ca
Read more

Steps on converting a Snapshot Standby database to Physical Standby database

-
Steps on converting a Snapshot Standby database to Physical Standby database: 1) Check for database role, open mode & Restore point create by this conversion. STDBY.SYS.SQL> set serveroutput on long 2000000 longchunksize 20000 pagesize 50000 linesize 1000 set trimspool on time on timi on feedback on verify off echo off heading on; col name for a65 col scn for 9999999999999999999999 col time for a40 col guarantee_flashback_database for a30 col db_unique_name for a15 select a.name db_name, a.db_unique_name, b.instance_name, b.instance_role, a.database_role, a.open_mode, a.protection_level, a.fs_failover_status, a.dataguard_broker, a.log_mode, a.force_logging, a.flashback_on from gv$database a, gv$instance b; select name, scn, time, guarantee_flashback_database, storage_size, database_incarnation# from gv$restore_point; 2) If the standby database is a RAC setup then we need to shutdown all the instances except one on which we will be using the conversion c
Read more

Flashback Database to Restore Point in Primary-Standby Environment

-
Flashback Database to Restore Point in Primary-Standby Environment: When we have a Data Guard environment (Primary RAC and Standby Standalone Databases) and we want Flashback database to restore point. We need to follow below steps. a) Always flashback the primary database first. Then follow below step for Standby. b) On the primary, connect using RMAN and list the incarnations. c) On the standby, cancel the recovery and flashback the standby to restore point created earlier. d) On the standby, connect using RMAN and list the incarnations. e) If there is a mismatch in incarnation between primary and standby then need to reset the incarnation of standby and start recovery (Details not available in this DOC). 1)    Disable Log Transport Services to the Standby Database for the Destination serving the Standby Database on all Primary Instances: $ dgmgrl sys/<Password>@<PRIM/STDBY> DGMGRL>  show database 'PRIM '; edit database '
Read more