昨天与一位有着20年的IT经验、10年Oracle经验的沈工聊天，其中提到oracle的后台进程有哪些都有各有什么作用，记着自己回答得不是很好，作为一个专职DBA这些很基础的理论知识学得不够扎实和牢固，众所周知，oracle的控制文件非常重要，我却用了
SQL>alter session set events ‘immediate trace name controlfile level 8’;
OR
SQL>alter database backup controlfile to trace;
严格的来说，这不是控制文件的备份，只是将当前控制文件转储，后续再可以用来重建控制文件，更严重的是这个命令我还写错了，大家也许会笑话我，不过没关系，我敢正视自己的问题和存在的不足，相信自己假以十日，我会做得更好。控制文件的备份方法有很多：
1. 如果条件允许，可以正常关闭数据库后用OS级的CP命令来备份。
2. 在全备份和其它备份时，指定include current controlfile子句。
3. 使用RMAN的如下功能：
RMAN>configure controlfile autoback on;
RMAN>backup current controlfile format ‘/path/control%s.ctl’;
如果是10g,还可以，
RMAN>backup as copy controlfile format ‘/path/control01.ctl’;
4. 在RMAN进行控制文件同步或备份的时候，oracle会自动执行控制文件的快照，这个快照在特殊情况下，也可以拿来恢复,快照的默认路径：$ORACLE_HOME/dbs,
可以用如下的命令更改默认路径：
RMAN>configure snapshot controlfile name to ‘/path/snapcf_<ORACLE_SID>.cf’;
在configure controlfile autoback on下，现在再备份数据库，备份集中将不包含自动的控制文件备份，自动控制文件备份发生在备份完成之后，现在的控制文件备份和快照都是来自备份完成之后。
注意：
最初我以为数据库在NOARCHIVELOG模式下RMAN是无法备份的，其实是可以备份的。数据库备份信息同时存储在控制文件和catalog里，如果使用catalog数据库，必须保证catalog数据库是打开的。而现在数据库处于NOARCHIVELOG模式，要使用RMAN来备份必须保证目标数据库在mount状态，不能是打开的。
最后还聊到IBM AIX的VMM，对于shrashing一词该如何解释，原意是“使逆行；使颠簸”，表示系统连续地paging in和out, 经常是系统缺乏内存的现象，这里有一些参考：
Tuning VMM kernel parameter in AIX for Oracle
做技术的就应该经常探讨、分享才能让人进步，发现自己的不足然后去弥补。
下面再次重温一下Oracle的后台进程。
Mandatory background processes:
Database Writer (DBWn)
The server process records 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 (buffers that can be overwritten when server processes need to read in blocks from the data files) are available in the Database Buffer
Cache. Database performance is improved because server processes make changes only in the Database Buffer Cache.
DBWn defers writing to the data files until one of the following events occurs:
• Incremental or normal checkpoint
• The number of dirty buffers reaches a threshold value
• A process scans a specified number of blocks when scanning for free buffers and cannot find any
• Timeout occurs
• A ping request in Real Application Clusters (RAC) environment
• Placing a normal or temporary tablespace offline
• Placing a tablespace in read-only mode
• Dropping or truncating a table
• ALTER TABLESPACE tablespace name BEGIN BACKUP
Log Writer (LGWR)
LGWR performs sequential writes from the Redo Log Buffer to the online redo log file under the following 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 files.
System Monitor (SMON)
If the Oracle instance fails, any information in the SGA that has not been written to disk is lost. For example, the failure of the operating system causes an instance failure. After the loss of the instance, the background process SMON automatically performs instance recovery when the database is reopened. Instance recovery consists of the following steps:
1. 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 file to the data blocks. Because all committed transactions have been written to the online redo log files, this process completely recovers these transactions.
2. Opening the database so that users can log on. Any data that is not locked by unrecovered transactions is immediately available.
3. Rolling back uncommitted transactions. They are rolled back by SMON or by the individual server processes as they access locked data.
SMON also performs some space maintenance functions:
• 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.
Process Monitor (PMON)
The background process PMON cleans up after failed processes by:
• Rolling back the user’s current transaction
• Releasing all currently held table or row locks
• Freeing other resources currently reserved by the user
• Restarts dead dispatchers
Checkpoint (CKPT)
Every three seconds the CKPT process stores data in the control file to identify that place in the online redo log file 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 Oracle9i, 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 to the headers of the data files.Checkpoints are initiated for the following reasons:
• To ensure that modified data blocks 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 to occur.
• 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, location in the online redo log file to begin recovery, information about logs, and so on.
Note: CKPT does not write data blocks to disk or redo blocks to the online redo log files.
Optional background processes:
• ARCn: Archiver
• 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: Advanced Queuing
• RECO: Recoverer
• Snnn: Shared Server
Archiver (ARCn)
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.
-The End-
