434
ORACLE常用後台進程說明
本文相對較為簡單，簡單介紹一下ORACLE後台進程（ORACLE的INSTANCE主體是由內存+後台進程組成），其中部分也是備份與恢複的關鍵點，本文主要說一下ORACLE後台進程的工作原理，首要分類的是將ORACLE後台進程分為：獨立模式、共享模式，我們一般采用獨立模式，也就是會話的後台進程是獨立的，共享模式相對來說有一個分配資源和並行處理的，所以用於MTS係統中，暫時不考慮這方麵的問題，簡單說下進程吧：
1、ORACLE進程查詢介紹
2、核心進程PMON說明
3、核心進程SMON說明
4、核心進程DBWR說明
5、核心進程LGWR說明
6、CKPT說明
8、其它一些進程
正文（跟著操作一遍即可）：
1、ORACLE進程查詢介紹
--首先登陸數據庫：
SQL> connect / as sysdba;
已連接。
--查看SGA的信息，10g才有的視圖
--ORACLE 10G後才可以使用的命令
SQL> select * from v$sgainfo;
NAME BYTES RES
-------------------------------- ---------- ---
Fixed SGA Size 1249992 No
Redo Buffers 7135232 No
Buffer Cache Size 398458880 Yes
Shared Pool Size 121634816 Yes
Large Pool Size 4194304 Yes
Java Pool Size 4194304 Yes
Streams Pool Size 0 Yes
Granule Size 4194304 No
Maximum SGA Size 536870912 No
Startup overhead in Shared Pool 50331648 No
Free SGA Memory Available 0
--看下SGA大小：
SQL> show parameter sga_t;
NAME TYPE VALUE
------------------------------------ ----------- -------------------
sga_target big integer 512M
--提取已經分配的後台進程：
SQL> select name,DESCRIPTION from v$bgprocess where paddr<>'00';
NAME DESCRIPTION
----- -----------------------------------------------------------
PMON process cleanup
PSP0 process spawner 0
MMAN Memory Manager
DBW0 db writer process 0
LGWR Redo etc.
CKPT checkpoint
SMON System Monitor Process
RECO distributed recovery
CJQ0 Job Queue Coordinator
QMNC AQ Coordinator
MMON Manageability Monitor Process
NAME DESCRIPTION
----- -----------------------------------------------------------
MMNL Manageability Monitor Process 2
在這裏看到很多進程，紅色標注部分全部為核心進程，CKPT雖然不是核心進程，但是也很重要，所謂核心進程是，實例中要是這些進程死掉了，實例隻有重啟，沒法處理，其餘非核心進程死掉，可以處理，通過ALTER SYSTEM REGISTER，即通過配置重新注冊一次，有部分修改的配置信息，須立即生效的，也是通過這個命令完成，下麵對核心進程和非核心進程說明一下。
2、核心進程PMON說明
全稱為：process cleanup ，表示進程清理，負責將死掉的進程殺掉，如連接到數據庫後，斷掉網絡這些進場將會被殺掉，如果是死鎖掉的，需要人工幹預後才能回收。
3、核心進程SMON說明
System Monitor Process：1、做資源回收、數據庫崩潰時自我修複。回收資源包含：排序的、回退的、DROP掉的表，將資源合並；2、當數據庫異常關閉時，啟動中SMON後台進程通過控製文件發現日誌文件和數據文件不一致，通過日誌文件恢複數據文件，而動作由SMON執行。
4、核心進程DBWR說明
db writer process 0（db代表DATABASE）：帶下標的，代表有一組後台進程，不帶下標的，都是獨立的一個進程運行；DBWR進程，最多20個，最少一個。一般和CPU有關係，根據CPU進行相應的設置。這類進程做一件事情就是寫髒數據的過程。dirty buffer。
DBWR觸發條件：
1、髒數據庫太多，沒有多餘的緩衝區來存放了。
2、超時 3秒左右
3、CKPT，檢查點觸發
4、數據庫備份
5、表空間離線或隻讀時
6、停止數據庫
可以看出，沒有說明COMMIT時會進程DBWR，那麼如果COMMIT了，但是沒有寫數據，在斷電、SHUTDOWN ABORT等情況下，數據不就沒有了嗎，後麵說道LGWR和CKPT時會連套起來說明。
SQL> select name,DESCRIPTION from v$bgprocess where name like 'DBW%';
NAME DESCRIPTION
----- ----------------------------------------------------------------
DBW0 db writer process 0
DBW1 db writer process 1
DBW2 db writer process 2
DBW3 db writer process 3
DBW4 db writer process 4
DBW5 db writer process 5
DBW6 db writer process 6
DBW7 db writer process 7
DBW8 db writer process 8
DBW9 db writer process 9
DBWa db writer process 10 (a)
NAME DESCRIPTION
----- ----------------------------------------------------------------
DBWb db writer process 11 (b)
DBWc db writer process 12 (c)
DBWd db writer process 13 (d)
DBWe db writer process 14 (e)
DBWf db writer process 15 (f)
DBWg db writer process 16 (g)
DBWh db writer process 17 (h)
DBWi db writer process 18 (i)
DBWj db writer process 19 (j)
5、核心進程LGWR說明
LGWR Redo etc：寫日誌文件，將日誌緩衝區的數據寫入在線日誌文件中。其寫法為：循環寫、順序寫，按組（GROUP）管理日誌文件（在前麵文章中有說明），一般默認三組，每個成員（GROUP下的一個日誌文件）最少4M大小，默認50M，同組下多個成員一起使用過一次後成為孿生兄弟，即相互拷貝，相互備份，因為它是保護數據的，它自己隻有自己保護自己，就想控製文件一樣。
LGWR觸發條件：
1、提交做COMMIT或ROLLBACK；
2、大於1M日誌未寫入磁盤
3、1/3日誌緩衝區未寫入磁盤
4、DBWR之前須先寫LGWR，也就是LGWR寫入的日誌文件的SCN號碼肯定是大於等於數據文件的
5、超時
LGWR會記錄什麼？
也就是做COMMIT的時候會將信息寫入日誌文件中，記錄的大致是字段地址、字段值、事務標誌。
很多人可能會問：既然這些信息都記錄了所有的插入數據文件的信息幹嘛還要寫日誌呢？
很簡單的答案：
1、第一使用日誌文件是輕量的，相對較為安全，若文件壞掉，絕大部分甚至全部數據可以找回。
2、日誌文件寫比數據文件寫要快很多，大家會發現日誌文件隻有一個LGWR進程，而DBWR有20，但是20也沒有LGWR一個快，主要有兩個方麵的原因：一個是日誌文件是順序寫，循環寫，它不用考慮下麵的位置，而數據文件需要找到實際的位置去修改並且需要分配磁盤空間；其次，數據文件修改後牽涉相關視圖的修改，若頻繁使用DBWR，在高並發係統中會很容易就出現瓶頸了，所以你COMMIT的時候，如果ORACLE把成功寫入在線日誌文件，它就向客戶反饋提交成功了。
6、CKPT說明
全稱checkpoint：這個概念一直很模煳，因為有個命令是ALTER SYSTEM CHECKPOINT，這裏的額CKPT是一個進程，而那個命令是調用這個進程來進程全局的磁盤寫，而CHECKPOINT還有一個在中文上很多時候把他稱為檢查點的概念，這個檢查點可以理解為一個已經被存盤的SCN號碼，也就是一個特殊的SCN號碼，他們都存在於數據文件頭、控製文件頭、日誌文件內部，通過V$DATABASE視圖以及表空間視圖、數據文件視圖、控製文件視圖都可以查到（在前麵文章已經說過），當日誌文件進行增量或者全部存盤時，會將起始的CHECKPOINT_CHANGE#編號，與需要存盤的SCN號碼對比（全量存盤以當前SCN號碼為準），將這部分髒塊寫入數據文件，並修改數據文件頭和控製文件頭的檢查點號碼。
簡單說下一下幾個問題：
為什麼用SCN號碼，不用時間戳？
因為係統時間是可以被改變的，SCN號碼永遠向上增長。
SCN號碼自動增長，會不會有上線？
是的，有的，不過很大，有這麼大:
SQL> select to_number('ffffffffffff','xxxxxxxxxxxxx') from dual;
TO_NUMBER('FFFFFFFFFFFF','XXXXXXXXXXXXX')
-----------------------------------------
2.8147E+14
以數據庫7*24不休息，每秒20萬次業務操作，則查詢一下40年使用多少：
SQL> select 40*365*24*3600*200000 FROM DUAL;
40*365*24*3600*200000
---------------------
2.5229E+14
即這樣下去最少可以使用四十多年，到四十多年後，ORACLE再給升級一下就搞定這些事情了。
說到第一個問題，COMMIT不寫數據文件，數據跑哪裏去了？
在LGWR中，COMMIT時是通過LGWR寫入在線日誌文件後反饋提交成功的，也就是要寫入數據文件的內容都在這裏麵可以找到。當你shutdown abort或者斷電時，然後重啟到MOUNT時，SMON進程通過控製文件發現檢查點記錄與日誌文件不協調，此時，就通過日誌文件增量構造DIRTY LIST，並進行存盤操作，然後啟動，這個過程對外部沒有任何效果，內部自動完成的。
同理，日誌文件壞掉了，所謂的RESETLOGS就是通過這個SCN號碼從新構造日誌文件；
初始化參數文件壞掉了，編輯一個；
控製文件壞掉了可以提前做一個TRANCE，其實也就是控製文件的空殼創建語句，自己也可以編輯一個，不過記得將臨時表空間引入（否則大SQL會報錯），然後通過日誌文件RECOVER一下。
關於數據文件壞掉不是一兩句話可以說明白的，後麵專門說這個，隻是也會涉及SCN號碼來回調用和介質恢複而已。
7、其它的一些進程說明：
ARCH進程：歸檔進程，在歸檔模式下，當所有在線日誌組全部寫滿的時候，再進行切換時，就會自動啟用ARCH進程，這些日誌文件被複製到一個或多個主機上，複製後，被稱為歸檔日誌文件。
CJQ0 Job Queue Coordinator：隊列進程，可以使用C000~C999的作業進程來運行。
Snnn：共享服務器進程，用於MTS係統。
Dnnn：共享服務器調度進程。
10g後的一些：
QMNn ：隊列監控進程。
MMON Manageability Monitor Process、MMNL Manageability Monitor Process 2：為自動工作區（AWR）手機數據庫的快照，根據調度將SGA的手機信息交給AWR。
MMAN：自動內存管理進程。
等等，如：RBAL、ASMB，11g中還有更多的進程。
最後更新：2017-04-02 06:51:22