Oracle後臺進程

轉自 http://blog.chinaunix.net/uid-20807166-id-1833979.html

 

後臺進程

爲了實現爲多用戶提供服務且保證系統性能，在一個多進程  Oracle 系統（ multiprocess Oracle system）中，存在多個被稱爲後臺進程（ background process）的  Oracle 進程。

一個  Oracle 實例中能夠包含多種後臺進程，這些進程不必定所有出如今實例中。系統中運行的後臺進程數量衆多，用戶能夠經過 V$BGPROCESS 視圖查詢關於後臺進程的信息。 Oracle 實例中可能運行的後臺進程有：

·數據寫入進程（ DBWn）

·日誌寫入進程（ LGWR）

·檢查點進程（ CKPT）

·系統監控進程（ SMON）

·進程監控進程（ PMON）

·恢復進程（ RECO）

·做業隊列進程

·歸檔進程（ ARCn）

·隊列監控進程（ QMNn）

·其餘後臺進程

在許多操做系統中，後臺進程在實例啓動時可以被自動地建立。

圖示

下圖顯示了後臺進程如何與  Oracle 數據庫的各部分交互，後續將講述這些後臺進程。

多進程  Oracle  實例中的後臺進程

本圖中間爲  SGA。上部爲  RECO， PMON，及  SMON 進程，其間的雙向箭頭表示各進程與實例間的通訊。下部左側爲  DBW0 和 LGWR 進程，這兩個進程分別和數據緩存區與重作日誌緩衝區進行通訊，同時還分別訪問數據文件和重作日誌文件。

本圖中還展現了一些其餘進程，例如  ARC0，須要訪問脫機存儲設備和控制文件；以及  CKPT，須要訪問數據文件和控制文件。

數據庫寫入進程（DBWn）

數據庫寫入進程 database writer process (DBWn)，將 buffer中的內容寫入數據文件中。 DBWn進程負責將在 buffer cache中的那些修改的 buffer，也就是髒數據寫入磁盤中。

對於大多數系統來講， 1個進程 (DBW0)就足夠了，但也能夠經過設置初始化參數 DB_WRITER_PROCESSES，增長數據庫寫入進程，編號從 DBW0-DBW9以及 DBWa-DBWj，最多能夠 20個進程。可是前提是必須有足夠多的 CPU供這些進程使用，在一個單 CPU的系統中，額外地配置該進程並不能提升性能，因此須要根據 CPU及處理器的個數決定如何設置該參數。

當一個 buffer在數據庫的 buffer cache中被修改了，就會被標記爲髒數據 (dirty)。 Buffer cache的冷端 (cold buffer)是指根據 LRU(least recently used)算法選擇出的，最近最少使用的 buffer。 DBWn進程將冷端的、髒的 buffer寫入磁盤，這樣用戶進程就能夠查找冷端、乾淨的 buffer用於將新的數據塊讀入 cache中。當一個 buffer被用戶進程修改 (弄髒 )，此 buffer就再也不是 free buffer，不能用於新數據的寫入。若是 free buffer數量過少，用戶進程就會找不到足夠的空間用於數據寫入。而 DBWn進程有效地管理了 buffer cache，讓用戶進程老是可以得到 free buffer。

DBWn進程老是將冷端、髒 buffer寫入磁盤， DBWn在改善查找 free buffer性能的同時，也另最近頻繁使用的 buffer保留在內存中。例如，儲存那些頻繁訪問且較小的表或索引的數據塊，能夠 keep在 cache中，不必反覆地從磁盤中讀取。因爲 LRU算法將訪問頻率高的數據塊保留在 buffer cache中，因此一個 buffer被寫入磁盤中，該 buffer所包含的數據被立刻訪問的機率較小。

知足如下條件時， DBWn進程會將髒數據緩衝區 (dirty buffers)寫入磁盤：

·當服務器進程掃描了必定數量的 buffer以後，沒有找到乾淨的可用的 buffer，它通知 DBWn寫入。 DBWn將 buffer寫入磁盤的操做是異步的，由於在 DBWn工做的同時還有其餘進程在執行。

· DBWn週期性地寫 buffer，從而使得 checkpoint前移， checkpoint是當一個實例須要實例恢復時，應用重作日誌的起始位置。這個位置是由 buffer中最先的髒數據緩衝區 (dirty buffers)決定的。

不管那種狀況， DBWn進程都是批量 (一次多數據塊 )地寫入以提升性能。一次批量寫入的數據塊的數量隨操做系統的不一樣而改變，沒有固定值。

日誌寫入進程（LGWR）

         日誌寫入進程 log writer process (LGWR)負責管理日誌緩衝區，將日誌緩衝區寫入磁盤上的日誌文件。 LGWR將從上次以後才複製到 buffer中的重作條目寫入磁盤。

         日誌緩衝區 (redo log buffer)是一個環形的緩衝區 (circular buffer)。當 LGWR進程將日誌緩衝區的重作條目寫入日誌文件，服務器進程同時也將新的條目複製到日誌緩衝區覆蓋那些已經寫入磁盤的條目。 LGWR一般須要保證足夠快地寫入，即便在頻繁訪問 redo log時也要確保緩衝區有足夠的空間用於寫入新的條目。

         LGWR將一部分連續的 buffer寫入磁盤。 LGWR寫入的內容有：

·一個用戶進程提交事務的提交記錄。

· Redo log buffer，如下 3個條件，知足其中一個就寫入。

·每三秒寫入一次。

·當日志緩衝區使用了三分之一。

·當 DBWn進程向磁盤寫入髒緩衝區，但須要寫入的日誌尚未寫入。

注意：

在 DBWn進程向磁盤寫入髒數據以前，全部與修改數據相關的重作記錄都必須被寫入磁盤，這就是先寫日誌原則 (write-ahead protocol)。若是 DBWn發現有一些重作記錄沒有寫入磁盤，會通知 LGWR將它們寫入，並等待將 LGWR進程將重作日誌緩衝區內的相關數據寫入磁盤後，才能將數據緩衝區寫入磁盤。

LGWR同步地向一個日誌組的多個鏡像成員寫入。若是其中的一個成員文件損壞了， LGWR繼續向其餘成員寫入，並將錯誤記錄到 LGWR進程的 trace文件和 alert log中。若是一個日誌組的全部成員文件都損壞了，或者日誌組因爲未歸檔而暫時不可用，那麼 LGWR就沒法繼續工做了。

         當用戶執行了一句 commit時， LGWR將提交記錄放進日誌緩衝區，而且將它與事務的重作條目一塊兒當即寫入磁盤。而相關的被修改的數據塊要等待更高效的時機時才寫入磁盤。這被成爲快速提交 (fast commit)機制。一個事務的提交記錄及相關的重作條目將經過一個原子性 (atomic)的寫操做記錄到磁盤上，這個單一事件決定了事務是否被成功地提交。儘管此時被修改的數據緩衝區尚未寫入磁盤， Oracle 已經可以向用戶返回事務提交成功的信息。

注意：

有時，若是重作日誌緩衝區內空間不足， LGWR 進程會在事務提交前就將重作日誌條目寫入磁盤。這樣的重作日誌條目只有在相關事務提交後才能永久地存儲。

         當一個用戶提交一個事務時，這個事務就被賦予了一個系統改變號 system change number (SCN)， Oracle 將在事務的重作條目中記錄此編號。 SCN是被記錄在 redo log中的，因此恢復 (recovery)操做能夠在 RAC、分佈式數據上同步地進行。

在數據修改操做較頻繁時， LGWR 進程可以採起 批量提交 (group commits)技術向重作日誌文件寫入數據。例如，當一個用戶提交了一個事務後， LGWR 進程會將此事務的重作條目（ redo entry）寫入磁盤，與此同時系統中的其餘用戶也可能在執行  COMMIT 語句。可是 LGWR 進程須要在以前的寫入操做完成後，才能爲後續的提交事務寫入重作信息。當第一個事務的重作條目被寫入磁盤後，在此期間等待提交的事物的重作條目能夠被一塊兒寫入磁盤，這比分別寫入每一個事務的重作條目所需的  I/O 操做要少。 Oracle 經過這種辦法減小了磁盤  I/O 並提高了  LGWR 進程的性能。若是系統中的提交頻率一直很高，那麼  LGWR 進程每次從重作日誌緩衝區向磁盤的寫入數據中都包含多個提交事務的信息。

檢查點進程（CKPT）

         當一個 checkpoint發生時， Oracle必須更新全部數據文件的文件頭，記錄這個 checkpoint的詳細信息。這個動做是由 CKPT進程完成的，可是 CKPT進程並不將數據塊寫入磁盤，寫入的動做老是由 DBWn 進程完成的。

         由企業管理器 (Enterprise Manager)的  System_Statistics 監視器顯示的 DBWR checkpoints統計信息顯示了系統中須要完成的檢查點操做。

系統監控進程（SMON）

實例啓動時若有須要，系統監控進程（ system monitor process， SMON）將負責進行恢復（ recovery）工做。此外， SMON 還負責清除系統中再也不使用的臨時段（ temporary segment），以及爲數據字典管理的表空間（ dictionary managed tablespace）合併相鄰的可用數據擴展（ extent）。在實例恢復過程當中，若是因爲文件讀取錯誤或所需文件處於脫機狀態而致使某些異常終止的事務未被恢復， SMON 將在表空間或文件恢復聯機狀態後再次恢復這些事務。 SMON進程按期檢查本身是否被須要，系統內的其餘進程發覺須要時也可以調用 SMON 進程。

         在  RAC 環境中，一個實例的  SMON 進程可以爲出錯的  CPU 或  實例進行實例恢復（ instance recovery）。

進程監控進程（PMON）

當一個用戶進程（ user process）失敗後，進程監控進程（ process monitor， PMON）將對其進行恢復。 PMON 進程負責清理數據緩衝區（ database buffer cache）並釋放用戶進程使用的資源。例如，它能夠重置活動事務表 (active transaction table)的狀態，釋放鎖，將某個進程 ID從活動進程列表中移除。

PMON 進程會週期性地對調度器（ dispatcher）和服務進程（ server process）進行檢查，從新啓動中止運行的進程（不包括  Oracle 有意中止的進程）。 PMON 進程還負責將實例和調度器進程的信息註冊到網絡監聽器（ network listener）。

同 SMON同樣， PMON進程按期檢查本身是否被須要，系統內的其餘進程發覺須要時也可以調用  PMON 進程。

恢復進程（RECO）

         恢復進程 recoverer process (RECO)用於分佈式數據庫結構，自動解決分佈式事務的錯誤。一個節點的 RECO進程會自動地鏈接到一個有疑問的分佈式事務的相關其餘數據庫。當 RECO從新鏈接到相關的數據庫服務時，它會自動地解決有疑問的事務。並從相關數據庫的活動事務表（ pending transaction table）中移除和此事務有關的數據。

         若是 RECO進程沒法鏈接到遠程服務， RECO會在必定時間間隔後嘗試再次鏈接。可是每次嘗試鏈接的時間間隔會以指數級的方式增加。只有實例容許分佈式事務時纔會啓動  RECO進程。實例中不會限制併發的分佈式事務的數量。

做業隊列進程（Job Queue Processes）

         通常由兩類進程組成：

做業隊列協調進程 coordinator job queue process (CJQn)，起到對做業隊列的監控做用。

執行做業的隊列進程 job queue processes (Jnnn)，由 CJQn完成調度產生。

做業隊列進程用於批處理，執行用戶 job，能夠將它們看作一個調度服務，用於調度 Oracle實例上如 PL/SQL語句或存儲過程的 job。提供開始的時間和調度的時間間隔，做業隊列進程能夠根據這個配置，自動地週期性地執行。

         做業隊列進程能夠被動態地管理。能夠容許做業隊列客戶端根據須要使用多個做業隊列進程，當一個做業隊列進程進入空閒狀態（ idle）後，其使用的資源將被釋放。

         動態的做業隊列進程能夠按指定的時間間隔運行大量的做業。用戶的做業是由  CJQ 進程交給做業隊列進程執行的。具體步驟以下：

1. 名爲  CJQ0 的協調進程（ coordinator process）按期地從系統 JOB$表中選擇須要運行的 job。被選出的做業將按照時間排序。

2. CJQ0進程動態地產生 job隊列的 slave進程來運行這些 job，編號從 J000-J999。

3. 做業隊列進程執行一個由  CJQ 進程選出的做業。每一個進程每次只能執行一個 job。

4. 當一個工做隊列進程執行完一個做業後，就可以接受下一個做業。若是此時系統中已經沒有須要被調度的做業了，此進程將進入休眠狀態（ sleep state）；此進程還會按期地甦醒（ wake up）等待分配其餘做業。若是在預設的時間內沒有新的做業，此進程將終止。

初始化參數 JOB_QUEUE_PROCESSES表示實例中能夠並行執行的最大做業隊列進程數。可是，客戶端不該該假設全部的做業隊列進程都用於執行 job。

注意：

若是初始化參數 JOB_QUEUE_PROCESSES被設置爲  0，協調進程 (CJQ )將不會被啓動。

歸檔進程（ARCn）

歸檔進程（ archiver process， ARCn）在發生日誌切換（ log switch）時將重作日誌文件複製到指定的存儲設備中。只有當數據庫運行在 ARCHIVELOG模式下，且自動歸檔功能被開啓時，系統纔會啓動 ARCn進程。

         一個  Oracle 實例中最多能夠運行  10 個  ARCn 進程（ ARC0 到  ARC9）。若是當前的  ARCn 進程還不能知足工做負載的須要， LGWR 進程將啓動新的 ARCn進程。 Alert log會記錄 LGWR啓動 ARCn進程。

         若是預計系統存在繁重的歸檔任務，例如將進行大批量數據裝載，能夠經過設置初始化參數 LOG_ARCHIVE_MAX_PROCESSES來指定多個歸檔進程，經過 ALTER SYSTEM語句能夠動態地修改該參數，增長或減小歸檔進程的數量。然而，一般不須要去改變該參數，該參數默認值爲 1，由於當系統負載增大時， LGWR進程會自動地啓動新的 ARCn進程。

隊列監控進程（QMNn）

         隊列監控進程是一個可選擇的進程，它提供 Oracle工做流高級隊列，用於監控信息隊列。能夠配置最多 10個監控進程。這些進程相似做業隊列進程與其餘  Oracle 後臺進程的區別在於，這兩類進程出錯不會致使整個實例出錯。

調度進程（Dnnn）

         調度進程 Dispatcher（ Dnnn）是一個可選的 Oracle後臺進程，只存在於共享服務器環境中。

內存管理進程（MMAN）

內存管理進程 Memory Manager(MMAN)是一個 SGA後臺進程。 10g新特性，自動共享內存管理 Automatic Shared Memory Management(ASMM)啓用時，會有這個新的後臺進程。 MMAN服務像是 SGA內存的經紀人 (SGA Memory Broker)同樣，協調內存各組成部分的大小。 SGA Memory Broker很清楚內存各組成部分的大小，和有待調整的操做。

恢復寫入進程 （RVWR）

Flashback Database是 Oracle10g的新增功能，在啓動 Flashback Database以後，它按期將已發生變化的塊寫入閃回日誌的日誌文件中。這些日誌不是由傳統的 Log Writer (LGWR) 過程寫入，而是由一種稱做 Recovery Writer (RVWR)的新過程寫入。

這是 Oracle10g的新增進程。閃回數據庫是指將數據庫返回到一個早前的數據庫狀態，閃回數據庫特性提供了一種快速的方法，將數據庫迅速地返回到早前的某個時間點，它不一樣於傳統的基於時間的恢復。

         數據庫閃回只能從如下錯誤中恢復：

·因爲邏輯錯誤致使的。

·因爲用戶錯誤致使的。

不能從介質錯誤中經過閃回特性恢復數據庫。

閃回數據庫所需的時間是與被改變的數據成正比的，而不是數據庫的大小。

注意，一旦 resetlogs以後，將不能再 flashback至 resetlogs以前的時間點。

內存管理進程 （MMON）

內存管理進程 memory monitor (MMON)是 10g的新進程，它聯合 AWR新特性負責執行多種和可管理性相關（ manageability-related）的後臺任務，例如：

·當某個測量值（ metrics）超過了預設的限定值（ threshold value）後提交警告

·建立新的  MMON 隸屬進程（ MMON slave process）來進行快照（ snapshot）

·捕獲最近修改過的  SQL 對象的統計信息

它的 slave進程是 M000。

其餘後臺進程

Oracle 數據庫中還可能運行其餘後臺進程。包括：

Memory Monitor Light (MMNL)進程負責執行輕量級的且頻率較高的和可管理性相關的後臺任務，例如捕獲會話歷史信息，測量值計算等。它與 AWR一塊兒起做用，將須要的 buffer統計信息寫入磁盤。

MMAN進程負責執行數據庫系統的內部任務。

在使用了自動存儲管理（ Automatic Storage Management）的實例中， RBAL 進程負責協調磁盤組間的負載平衡工做。她可使多個實例同時訪問一個  ASM 磁盤（ global open）。最終由  ORBn 進程實際執行數據擴展的負載均衡。實例中能夠運行多個  ORBn 進程，分別爲 ORB0， ORB1，以此類推。

當數據庫實例使用  ASM 磁盤組時，還要啓動  OSMB 進程。此進程負責和  ASM 實例（ Automatic Storage Management instance）通訊。

LMS（ Global Cache Service）進程，在 RAC環境中存在，該進程管理資源，並提供實例資源交互控制。

Change Tracking Writer (CTWR)進程，是 10g中的新進程，用於對最近的改變的塊進行跟蹤，讓 RMAN能夠更快地進行增量備份。