[Ora10, 4] oracle background process Introduction:, ora10oracle

[Ora10, 4] oracle background process Introduction:, ora10oracle
1. SMON (System MONitor) System monitoring process:

During database startup, SMON is placed after the CKPT process and in Oracle9i, it is placed at the sixth position:

PMON started with pid = 2
DBW0 started with pid = 3
LGWR started with pid = 4
CKPT started with pid = 5
SMON started with pid = 6
RECO started with pid = 7

SMON is responsible for system monitoring and cleaning and recovery of some systems, including:
1. Clear temporary space and temporary segments
SMON is responsible for clearing the temporary segments in the temporary tablespace when the database is started, or temporary segments left behind by some abnormal operations, such as when an index is created, the Segment allocated to the Index during creation is marked as TEMPORARY. If the Create Index (or rebuild Index, etc.) Session is interrupted due to exceptions, SMON is responsible for clearing these TEMPORARY segments.
2. Join idle Space
In DMT (dictionary management tablespace), SMON is responsible for concatenating Extent that are idle in the tablespace and are adjacent to each other into a large idle expansion zone, this requires that the pctincrease of the tablespace be set to a non-zero value.
3. Execute Instance recovery)
During instance recovery, SMON involves three steps: Application Redo rollback, database access, and uncommitted data rollback.

Tue Apr 22 21:31:10 2008
SMON: enabling cache recovery
Tue Apr 22 21:31:10 2008
ARC0: Completed archiving log 1 thread 1 sequence 238
Tue Apr 22 21:31:11 2008
Undo Segment 1 Onlined
Undo Segment 2 Onlined
Undo Segment 3 Onlined
Undo Segment 4 Onlined
Undo Segment 5 Onlined
Undo Segment 6 Onlined
Undo Segment 7 Onlined
Undo Segment 8 Onlined
Undo Segment 9 Onlined
Undo Segment 10 Onlined
Successfully onlined Undo Tablespace 1.
Tue Apr 22 21:31:11 2008
SMON: enabling tx recovery
Tue Apr 22 21:31:11 2008
Database Characterset is ZHS16GBK
Replication_dependency_tracking turned off (no async multimaster replication found)
Completed: ALTER DATABASE OPEN

4. Offline rollback segments
In the automatic rollback segment Management (AUM), it is responsible for the rollback segments that are no longer needed by Offline. The following information is recorded in the log:

Fri May 2 15:43:21 2008
SMON offlining US = 11
SMON offlining US = 12
SMON offlining US = 13
SMON offlining US = 14
SMON offlining US = 15
SMON offlining US = 16
SMON offlining US = 17
SMON offlining US = 18
SMON offlining US = 19
SMON offlining US = 20
SMON offlining US = 21
SMON offlining US = 22
SMON offlining US = 23

5. Execute parallel recovery
The following information comes from 9i logs:

Fri May 11 21:30:45 2007
SMON: Parallel transaction recovery tried

Also RecordSome English Note About SMON:

The SMON background process performs all system monitoring functions on the Oracle database. the SMON process performs a "warm start" each time that Oracle is re-started, ensuring that any in-flight transaction at the time of the last shutdown are recovered. for example, if Oracle crashed hard with a power failure, the SMON process is attached at startup time, and detects any uncompleted work, using the rollback segments to recover the transactions. in addition, SMON performs periodic cleanup of temporary segments that are no longer needed, And also perform tablespace operations, coalescing contiguous free extents into larger extents. Source: http://www.eygle.com/archives/2008/05/oracle_smon_process.html>  

6. Maintain the SMON_SCN_TIME system table. The SMON_SCN_TIME table records the relationship between SCN and time. the SMON table regularly updates the table and regularly deletes some older data. II. PMON (Process MONitor) Process monitoring Process: 1. role: it is mainly used to roll back a transaction that is terminated abnormally or forcibly terminated by the user. <1>. rolling back the transaction. <2>. releasing locks. release the lock. <3>. releasing other resources. <4>. restarts dead dispatchers. restart the dead scheduler. (used on the Shared Server ).
<5>. as the first background process started by the instance, PMON also monitors other Oracle background processes and restarts these background processes if necessary. <6>. in addition, PMON registers instances with the TNS listener. 2. pmon release lock Case: http://www.askmaclean.com/archives/microoracle-pmon-release-lock.htmlsan.dbwn database write process: 1. Role: Write Data in the memory to the disk. 2. DBWR write conditions: Check Points occur, and dirty cache reaches the limit. No free cache timeout occurs. RAC ping requests the tablespace offline tablespace read-only table to be deleted or truncated start the backup tablespace. The following figure is similar to the one found on the Internet: 1) when a process scans the secondary LRU and primary LRU linked lists to find the buffer header that can be overwritten [idle buffer, if the number of buffer headers that have been scanned reaches a certain limit (determined by the hidden parameter: _ db_block_max_scan_pct), The DBWR process is triggered. _ Db_block_max_scan_pct indicates the percentage of buffer headers scanned to the total number of buffer headers on the LRU linked list. At this time, the process for searching for available buffer headers is suspended. In v $ session_wait, the process waits for the "free buffer wait" event, and the value of "dirty buffers inspected" in v $ sysstat is increased. (Can query by x $ kvit) 2) When DBWR finds the buffer header that has been updated and is waiting to be written into the data file on the master LRUW linked list, if the number of buffer headers found exceeds a certain limit (determined by the hidden parameter _ db_writer_scan_depth_pct), DBWR will no longer continue scanning, go to the secondary LRUW linked list and write the dirty data blocks on it into the data file. _ Db_writer_scan_depth_pct indicates the percentage of the number of dirty data blocks scanned to the total number of buffer headers on the master LRUW linked list. 3) if the total number of dirty data blocks on the primary LRUW linked list and the secondary LRUW linked list exceeds a certain limit, the DBWR process will also be triggered. This limit is determined by the hidden parameter _ db_large_dirty_queue. 4) DBWR is triggered when an incremental checkpoint or a complete checkpoint occurs. 5) Start DBWR once every three seconds. 6) DBWR is triggered when the tablespace is set to offline. 7) issue the command: alter tablespace... Begin backup to trigger DBWR when the tablespace is set to the Hot backup state. 8) When the tablespace is set to read-only, DBWR is triggered. 9) when an object is deleted (such as deleting a table), DBWR is triggered. 3. number of database write processes in the system: 32-bit system, with a maximum of 10 processes named from dbw0 ---- dbw9 64-bit system, with a maximum of 20 processes named from dbw0 ---- dbw9, dbwa ----- dbwj.4. view the data volume of the dbwr process: SQL> show parameter db_writer_processes
Name type value ------------------------------------ db_writer_processes integer 1 The number of dbwr processes is set to dbwr process size = cup/8; 4. log writing process LGWR 1. LGWR write condition: When 1/3 of the log cache is reached during submission, the log size is 1 M every three seconds before the DBWn process writes. The following figure shows the similarities from the Internet: 1) timeout (timeout) When LGWR is idle, it depends on rdbms ipc message waiting and is in sleep state, until the time-out period of 3 seconds is reached. If LGWR finds that redo needs to be written, LGWR will execute the write operation, and the log file parallel write wait event will appear. 2) When the threshold value reaches, as long as a process allocates space in the log buffer, the number of used Log buffer will be calculated. If the number of blocks used is greater than or equal to the value set by the _ log_io_size parameter, the LGWR write operation is triggered. If LGWR is not active at this time, LGWR will be notified to perform the background write operation. The default _ log_io_size is equal to 1/3 log buffer. The upper limit is 1 MB. this parameter is 0 in X $ KSPPSV, indicating the default value. That is, LGWR will be triggered in Min (1 M, 1/3 log buffer size. Note that the log buffer size here is measured by log block. This value is usually 512 bytes. 3) when a transaction is committed, a commit flag is recorded in redo stream. Before these redo logs are written to a disk, this transaction cannot be recovered. Therefore, before the transaction returns a success mark to the user, you must wait until the LGWR write is complete. The process notifies LGWR to write and starts to sleep with the log file sync event. The timeout time is 1 second. The implicit parameter _ wait_for_sync of Oracle can be set to false to avoid waiting for redo file sync, but the restoration of the transaction cannot be guaranteed. note that the commit in the recursive call (recursive CILS) (such as the commit in the process) does not need to synchronize redo until the response is returned to the user. Therefore, recursive calls only need to synchronously return the RBA of the last Commit operation before the call to the user. There is an SGA variable used to record the log block number to be synchronized by the redo thread. If multiple commits occur before LGWR is awakened, this variable records the highest log block number, and all redo records before this are written to the disk. This is sometimes called group commit ). 4) before DBWR is written, if the high RBA of the data to be written by DBWR exceeds the on-Disk RBA of LGWR, DBWR writes the post LGWR file. Before Oracle8i, DBWR waits for the log file sync event. Starting from Oracle8i, DBWR puts these blocks into a defer queue and notifies LGWR to execute redo writing. DBWR can continue to execute Data Writing without waiting. 2. log buffer, which is written to the logfile through lgwr. CKPT (Checkpoint) Checkpoint Process: 1. function: updates the checkpoint information of the control file and data file header. The CKPT process also notifies the DBWn process to perform write operations. The checkpoint information includes the checkpoint position, SCN, and Redo recovery position. Send a signal to DBWn and rewrite the data. Update Data File Header update control file 2. Trigger condition for CKPT to send CHECKPOINT signal:

1) The log_checkpoint_timeout time reaches 2) The current redo log has been written enough log_checkpoint_internavl * the size of the operating system block 3) redo log switmethane) alter system checkpoint5) alter tablespace XXX begin backup/end backup 6) alter tablespace, datafile offline, shutdown immediate, direct read;

Vi. Archiver (ARCn): 1. Role: archive the log process is the most important process in Oracle's optional background processes. If data files in the Oracle database are lost or damaged, full recovery should be performed in archive mode. In Oracle, redo log files are divided into multiple groups. When a set of redo log files are fully written, write a group, called Log switching. Log switching is performed cyclically. When the last group is full, write the first group again. If Oracle runs in non-archive mode, the log file overwrites will occur. In archive mode, ARCn will copy the redo log file after switching to the archive log file. Oracle ensures that the redo log files of this group are not overwritten before the archiving of a group of redo logs is complete. 2. show the number of SQL statements in the archiving process> show parameter log_archive_max_processes NAME TYPE VALUE ------------------------------------------------ log_archive_max_processes integer 4 3. modify the number of archiving processes: SQL> alter system set log_archive_max_processes = 5; the system has changed.


6. the RECO process is responsible for automatically recovering the failed distributed transactions in the distributed database environment to ensure the consistency of distributed transactions. In distributed transactions, either commit or rollback at the same time; 7. ARCH process: This process copies the filled online log files to the specified storage device. When the database is running in archive mode, the archiving process is responsible for copying the fully-filled redo log files to the archiving target after switching logs.
8. LCKn processes are used in environments with parallel server options. Up to 10 processes (LCK0, LCK1 ......, LCK9), used for blocking between instances. 9. MMAN process memory management. If SGA automatic management is set, MMAN is used to coordinate the size setting and size adjustment of each component in SGA. 10. MMON process management Monitor, which is mainly used for AWR and ADDM. MMON writes the statistical results from SGA to the system table. MMON: The Manageability Monitor (MMON) process was introduced in 10g and is associated with the automated Workload Repository new features used for Automatic problem detection and self-tuning. MMON writes out the required statistics for AWR on a scheduled basis.
Process address: http://blog.csdn.net/tianlesoftware/article/details/55877887.vm time progress: (oracle 11g new)
VKTM-its full name is V irtual Keeper of TiMe-Virtual Clock process, which is introduced in Oracle Database 11g, it is used for the virtual time clock provided by the internal part of a data warehouse in the middleware to calculate various time interval measurements. The introduction of VKTM reduces the interaction with the operating system, this improves performance. VKTM has two running modes: • basic mode, which can be updated at intervals of seconds; • or as a reference time counter. This mode is updated every 20 milliseconds and is only available at a high priority. For different versions, the VKTM setting mode may be different. For details, refer to the alarm log file.

VIII. v $ PROCESS view: the v $ process view in the database allows you to find information about each PROCESS corresponding to the operating system:
SQL> select addr, pid, spid, username, program from v $ process;
Addr pid spid username program -------- ---------- --------------------- 20172c61627c 1 pseudo do2c616830 2 5074 oracle @ master (PMON) 2C616DE4 3 5078 oracle @ master (PSP0) 2C617398 4 5080 oracle @ master (MMAN) 2C61794C 5 5082 oracle @ master (DBW0) 2C617F00 6 5084 oracle @ master (LGWR) 2C6184B4 7 5086 oracle @ master (CKPT) 2C618A68 8 5088 oracle @ master (SMON) 2c600001c 9 5090 oracle @ master (RECO) 2C6195D0 10 5092 oracle @ master (CJQ0) 2C619B84 11 5094 oracle @ master (MMON)
Addr pid spid username program -------- ---------- ------------------- 20171000012 5096 oracle @ master (MMNL) 2C61A6EC 13 5098 oracle @ master (D000) 2C61ACA0 14 5100 oracle @ master (D001) 2C61B254 15 5102 oracle @ master (S000) 2C61B808 16 5104 oracle @ master (TNS V1-V3)

In the query output of v $ process, the SPID column represents the process number on the operating system. Through SPID, You can associate the process from the operating system to the database: 9. search for background processes: SQL> select * from v $ bgprocess where paddr <> '00 ';
CPU usage in Oracle background processes

Process Structure of an Oracle instance

Here we are talking about the process of a Unix system. In Windows, Oracle is an operating system service.

The memory area of the Oracle instance and the background process.

To a single process instance (the process executes all the Oracle code and only allows access to a single user) and multi-process instance Oracle instance (Oracle code is executed by multiple processes in different parts, there is a process for each connected user, which allows multiple users to use at the same time ).

In the multi-process architecture, apart from server processes (please note that this "server process" does not refer to all process instances, please refer to the instructions below), there are other background processes, including: dnnn, DBWR, LGWR, ARCH, PMON, SMON, CKPT, and RECO are used. The operating system where these processes reside after the database is started. All processes and processes in Oracle cannot exceed the set value parameter process:

SQL> display parameter Process

When the Oracle client application is connected to the Oracle instance, Oracle will generate a server process for these customers, which is the thread performance under widnows. The main role of this process is to parse, compile, and execute the SQL statements issued by the user of the user's SQL statement. If the data block is absent, when the data buffer zone, the SGA shared data buffer that is read from the data file on the disk is an application that runs the result set returned by the SQL statement. Use the following statement to query user session information in the database.

SQL> select SUBSTR (1, 3 s. sid) SID, SUBSTR (s. serial #,) SER, SPID, SUBSTR (SCHEMANAME,) architecture, SUBSTR (type, 1, 3) typical, SUBSTR (Decoding (consistent_gets "+ block_gets"), 0, 'none', (100 * (consistent_gets + block_gets physical_reads)/consistent_gets + block_gets),) "% hit", valuable cpu, SUBSTR (block_changes) bchng V $ PROCESS p, V $ SESSTAT tons, V $ sess_io I, V $ session s I. sid = s. sid p. addr = PADDR (+) and s. sid = t. sid t. statistic # = 12;

Result:

SID indicates the session ID

SER indicates session serial #

SPID indicates the system process ID of the operating system. The serial number and serial number are combined to represent the SID of a single session,

Architecture

A typical example is the database user name, process type, user use process, and BAC % hit indicates the hit rate of the data buffer of the background process,

CPU, CPU usage time,

Bchng indicates the number of data blocks. /> The following describes different background processes.

1. DBWR Process

DBWR (Database writer) manages the buffer zone for writing data into data files.

When the data in the data buffer is marked as "dirty", the DBWR process is responsible for "dirty" data being written to the disk. /> DBWR uses the LRU algorithm to replace data in the data buffer zone.

DBWR has the following functions:

1) manage the data buffer so that the server process can always find the idle buffer zone

2) All the buffer data has been written to the database file. 3) the block recently used by the LRU algorithm is retained in the memory.

4) Optimize disk I/O through delayed write.

In the following cases, DBWR dirty data is written to the disk data file:

1) when a server process caches the data block "dirty table", the dirty surface expression is transferred to a certain extent. (The critical length is determined by the DB_BLOCK_WRITE_BATCH parameter)

2) When a server process finds the buffer DB in the LRU table... the remaining full text>
 
Oracle background process

In fact, you can find it online...
You can see it yourself...
Linsea.javaeye.com/blog/479663