Oracle 後臺進程

後臺進程

爲了實現爲多用戶提供服務且保證系統性能，在一個多進程 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可以更快地進行增量備份。

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