Oracle 體系結構三 後臺進程

實例後臺進程在啓動實例時啓動，在終止實例時終止運行。

 

 

SMON

SMON（system monitor）起初的任務是安裝和打開數據。SMON經過查找和驗證數據庫控制文件來安裝數據庫。此後，它經過查找和驗證全部數據文件和聯機日誌文件，來打開數據庫。一旦打開數據庫並使數據庫處於使用狀態後，SMON就負責執行各類內部管理任務，如合併數據文件中的可用空間。

 

系統監視器（System Monitor）要完成全部「系統級」任務。PMON感興趣的是單個的進程，而SMON與之不一樣，它以系統級爲出發點，這是一種數據庫「垃圾收集器」。SMON所作的工做包括如下幾種：

 

• • 清理臨時空間：例如，創建一個索引時，建立時爲索引分配的區段標記爲TEMPORARY。若是處於某種緣由CREATE INDEX會話停止了，SMON就要負責清理。其餘操做建立的臨時區段也要有SMON負責清理。

 

• • 合併空閒空間：若是你在使用字典管理的表空間，SMON要負責取得表空間中相互連續的空間區段，並把它們合併爲一個更大的空閒區段。只有當字典管理的表空間有一個默認的存儲子句，並且pctincrease設置爲一個非0值時，纔會出現空閒空間的合併。

 

• • 針對原來不可用的文件恢復活動的事務：這相似與數據庫啓動時SMON的做用。在實例/崩潰恢復時因爲某個文件（或某些文件）不可用，可能會跳過一些失敗的事務（即沒法恢復），這些失敗事務將由SMON來恢復。例如，磁盤上的文件可能不可用或未裝載，當文件確實可用是，SMON就會由此恢復事務。

 

• • 執行RAC中失敗節點的實例恢復：在一個Oracle RAC配置中，集羣中的一個數據庫實例失敗時（例如，實例所在主機失敗），集羣中的另外某個節點會打開該失敗實例的重作日誌文件，併爲該失敗實例完成全部數據的恢復。

 

• • 清理OBJ$：OBJ$是一個低級數據字典表，其中幾乎對每一個對象（表、索引、觸發器、視圖等）都包含一個條目。不少狀況下，有些條目表示的多是已經刪除的對象，或者表示「not there」對象（「not there」對象是Oracle一來機制中使用的一種對象）。要有SMON進程來刪除這些再也不須要的行。

 

• • 收縮回滾段：若是有設置，SMON會自動將回滾段收縮爲所設置的最佳大小。

 

• • 「離線」回滾段：DBA有可能讓一個有活動事務的回滾段離線（offline），或置爲不可用。也有可能活動事務會使用離線的回滾段。在這種狀況下，回滾段並無真正離線；它只是標記爲「簡要離線」。在後臺，SMON會按期嘗試真正將其置爲離線，知道成功爲止。

 

除此以外，它還會作許多其餘的事情，如將DBA_TAB_MONITIRING視圖中的監視統計信息刷新輸出，將SMON_SCN_TIME表中的SCN-時間戳映射信息刷新輸出，等等。隨着時間的推移，SMON進程可能會累計地佔用大量CPU時間，這應該是正常的。SMON會按期地醒來（或者被其餘後臺進程喚醒），來執行這些維護工做。

 

PMON

用戶會話是鏈接到服務器進程的用戶進程。服務器進程在此會話建立時啓動，在會話結束時銷燬。從會話中有序退出涉及用戶註銷。在這種狀況下，用戶執行的任何工做都將有序完成，服務器進程將終止。若是以無序方式終止會話（多是用戶計算機從新啓動），那麼會話將處於一個必須進行清理的狀態。PMON（process monitor）監視全部服務器進程，並檢測會話中的任何問題。若是會話異常終止，PMON將銷燬服務器進程，將其PGA內存返回給操做系統的空閒內存池，並回滾任何尚在進行的未完成事務。

進程監視器（Process Monitor）負責在出現異常停止的鏈接以後完成清理，還負責監視其餘的Oracle後臺進程，並在必要時重啓這些後臺進程，也可能適當地停止實例。PMON還會爲實例作另外一件事，這就是向Oracle TNS監聽器註冊這個實例。實例啓動時，PMON進程會詢問公認的端口地址（1521），來查看是否啓動並運行了一個監視器。若是數據庫實例啓動時有監聽器在運行，PMON會與這個監聽器通訊，並向它傳遞相關的參數，如服務名和實例的負載度量等。若是監聽器未啓動，PMON則會按期地試圖與之聯繫來註冊實例。（12c中由LREG來實現此功能）

DBWn

會話一般並不將數據寫入磁盤。會話將數據（或現有數據的更改）寫入數據庫緩衝區緩存中的緩衝區。由數據庫寫入器負責隨後將緩衝區寫入磁盤。一個實例可能有多個數據庫寫入器（最多不超過100個），一次稱爲DBW0到DBW9，而後是DBWa到DBWz，超過36的寫入器命名爲BW36到BW99。默認數量是每8個CPU對應一個數據庫寫入器（向上舍入）。在如下4種狀況下，DBWn將執行寫操做：沒有任何可用緩衝區、髒緩衝區過多、遇到三秒超時或遇到檢查點。

沒有任何可用緩衝區的狀況：若是服務器進程須要將塊複製到數據庫緩衝區緩存中，首先必須查找空閒的緩衝區。這種緩衝區是指既不髒（更新過，但還沒有寫回磁盤）也未被佔用（即相應時刻正被另外一個會話使用）的緩衝區。不能重寫髒緩衝區，不然將丟失已更改的數據，也不能重寫被佔用的緩衝區，由於操做系統的內存保護機制不容許這麼作。若是服務器進程超找空閒緩衝區用時過長（具體時限由Oracle內部肯定），就會通知DBWn將某些髒緩衝區寫入磁盤。一旦完成，緩衝區就是乾淨的，也就有了空閒的緩衝區可用。

髒緩衝區過多：這是由另外一個內部閾值肯定的。

遇到三秒超時：DBWn沒三秒鐘會對一些緩衝區清理一次。在實踐中，這對生產系統影響不大，由於前面描述的兩種狀況將強制執行寫入，但超時意味着：即便系統處於閒置狀態，最終也會清理數據庫緩衝區緩存。

可能存在請求的檢查點：前面列出的三個緣由將致使DBWn將有限數量的髒緩衝區寫入數據文件。而當遇到檢查點時，會寫入全部髒緩衝區。因前三個緣由而寫入緩衝區稱爲增量檢查點，或提升增量檢查點位置。這是在正常運行過程當中應該執行的，並進行優化，使緩衝區根據須要來提供，而不會給I/O系統增長壓力，而影響了性能。這意味着可能有幾十萬個髒緩衝區。在檢查點期間，磁盤I/O數量將達到頂峯，CPU使用率可能高達100%，最終用戶會話的性能將降低。當完成檢查點後（這可能須要數分鐘的時間），性能將恢復到一般的狀態。惟一絕對須要檢查點的時刻是：關閉了數據庫，關閉了實例。檢查點將多有髒緩衝區寫入磁盤：這就實現了緩衝區緩存與數據文件的同步，實例與數據庫的同步。在一般的運行狀態下，數據文件始終是過期的：它們缺乏多個更改（提交的更改或未提交的更改）。這不會帶來問題：由於緩衝區緩存中的數據塊副本是最新的，而會話使用的正是這些數據塊。在關閉期間，有必要將全部內容寫入磁盤。更經常使用的是局部檢查點，局部檢查點強制DBWn寫入僅包含一個或多個數據文件（而不是整個數據庫）的塊的全部髒緩衝區：在數據文件或有表空間脫機時；在將表空間植入備份模式時；或在將表空間設置爲只讀時。與徹底檢查點相比，這些檢查點的力度較小，每次在相關事件發生時自動執行。

Oracle切換日誌文件時就會標記（創建）一個檢查點。Oracle須要推動檢查點，推動檢查點後，就再也不須要它剛填滿的在線重作日誌文件了。若是須要重用這個重作日誌文件，而此時它還依賴於原來的重作日誌文件，咱們就會獲得一個「檢查點未完成」消息，而不惜等待。

能夠看到，DBWn的性能可能很重要。若是它寫出塊的速度不夠快，不能很快地釋放緩衝區（能夠重用來緩存其餘塊），就會看到Free Buffer Waits和Write Complete Waits的等待數和等待時間開始增加。 

最好的狀況下，DBWn使用異步I/O將塊寫至磁盤。採用異步I/O，DBWn會收集一批要寫的塊，並把它們交給操做系統。DBWn並不等待操做系統真正將塊寫出；而是當即返回，並收集下一批要寫的塊，當操做系統完成寫操做時，它會異步地通知DBWn寫操做已經完成。這樣，與全部工做都串行進行相比，DBWn能夠更快地工做。

關於DBWn，還有最後一點說明。根據定義，塊寫入器會把塊寫出到全部磁盤，即分散在各個磁盤上；也就是說，DBWn會作大量的分散寫（scattered write）。執行一個更新時，你會修改多處存儲的索引塊，還可能修改隨機地分佈在磁盤上的數據塊。另外一方面，LGWR則是向重作日誌完成大量的順序寫（sequential write）。這是一個很重要的區別，Oracle之因此不只有一個重作日誌和LGWR進程，還有DBWn進程，其緣由就在於此。分散寫比順序寫慢多了。經過在SGA中緩存髒塊，並由LGWR進程完成大規模順序寫（可能重建這些髒緩衝區），這樣能夠提高性能。DBWn在後臺完成它的任務（很慢），而LGWR在用戶等待時完成本身的任務（這個任務比較快），這樣咱們就能獲得更好的總體性能。儘管從技術上講這樣會使Oracle執行更多沒必要要的I/O（寫日誌以及寫數據文件），但總體性能仍是會提升。從理論上講，若是提交期間Oracle已經將已修改的塊物理地寫出到磁盤，就能夠跳過寫在線重作日誌文件。但實際中並非這樣：LGWR仍是會把每一個事務的重作信息寫至在線重作日誌，DBWn則在後臺將數據庫塊刷新輸出到磁盤。

LGWR

LGWR（log writer）將日誌緩衝區的內容寫入到磁盤上的聯機日誌文件中。將日誌緩衝區寫入聯機重作日誌文件的過程一般稱爲「日誌緩衝區轉儲」。

當會話對數據庫緩衝區緩存中的塊執行任何更改時，在其將更改應用到塊以前，會將要應用的變動向量寫入磁盤。爲此LGWR將日誌緩衝區的內容幾乎實時地傳輸到聯機重作日誌文件中。當會話發出COMMIT時，LGWR會實時寫入：在LGWR將緩衝區寫入磁盤時，會話將掛起。只有此時纔將事務記錄爲已經提交（所以是不可逆的）。

 

在如下3種狀況下，LGWR將轉儲日誌緩衝區：DBWn要寫入髒緩衝區；任何事務發出一個提交時；重作日誌緩衝區1/3滿。

提交時寫入：爲了處理COMMIT，服務器進程在日誌緩衝區中插入提交記錄。在LGWR將緩衝區寫入磁盤時，會話將掛起。只有此寫操做完成時，才能將提交完成的消息返回給會話，服務器進程才能繼續工做。這將確保事務永不丟失：已提交事務的每一個變動向量均可以在磁盤的重作日誌上獲得，並能夠在伺候應用於數據文件備份。所以，若是數據庫被破壞，那麼能夠經過備份進行還原，並且能夠重作自備份以來執行的全部工做。

重作日誌緩衝區的佔用率達到1/3：此時，LGWR會將日誌緩衝區轉儲到磁盤。這與性能相關。若是日誌緩衝區較小（一般也應該這樣），即便沒有回話提交事務，佔用率達到1/3的相應觸發器將強制LGWR將緩衝區準實時寫入磁盤。就大多數應用程序而言，日誌緩衝區的優化大小僅爲數MB。應用程序將在幾分之一秒的時間內生成足以填充1/3的重作內容，所以會強制LGWR將變動向量不斷地準實時寫入磁盤。此後，當會話發出COMMIT命令時，幾乎沒有任何要寫入的內容：COMMIT命令能夠當即完成。

DBWn要將髒緩衝區從數據庫緩衝區緩存寫入到數據文件中：在執行此操做前，它會通知LGWR將日誌緩衝區轉儲到聯機重作日誌文件中。這樣作能夠確保：始終能夠反轉未提交的事務。此處須要瞭解，DBWn徹底可能將未提交的事務寫入數據文件。只要必定可以得到反轉事務所需的撤銷數據，這就不成問題。在生成撤銷數據時，也會生成變動向量。在更新數據文件前，這些已經在重作日誌文件中，若有必要，能夠重建回滾事務所需的撤銷數據。注意，致使LGWR執行寫入的三秒超時是存在的。超時實際上在DBWn上，但因爲LGWR老是先於DBWn執行寫入，LGWR上也就有了三秒鐘的超時。 

CKPT

檢查點進程（Checkpoint Process）並不像它的名字所暗示的那樣真的創建檢查點，創建檢查點主要是DBWn的任務。CKPT只是更新數據文件的文件首部，以輔助真正創建檢查點的進程（DBWn）。當前檢查點位置，是發生實例故障時重作流中必須由此開始的恢復位置。CKPT使用當前檢查點位置不斷更新控制文件。

MMON

MMON（manageability monitor）是數據庫的不少自我監視和自我調整功能的支持進程。此數據庫實例收集有關活動和性能的大量統計數據，這些統計數據收集到SGA中，經過發出SQL查詢，能夠查詢它們的當前值。爲了調整性能，也爲了分析趨勢和得到歷史報告，有必要將這些統計數據保存到長期存儲的地方。MMON從SGA按期捕獲統計數據（默認是每小時一次），並將它們寫入到數據字典中，能夠無限期地存儲它們（不過，默認方式是隻存儲8天）。MMON還持續監視數據庫和實例，來肯定是否應該發出任何警報。

MMNL

MMNL（manageability monitor light）是MMON的輔助進程。有時，MMON的預訂活動顯得不足。例如，MMON根據調度安排將SGA中收集的統計信息轉儲到數據庫中：默認方式下是每小時一次。若是在MMON預約執行轉儲前，用於收集此信息的內存緩衝區變慢，那麼，MMNL將擔當起轉儲數據的職責。

MMAN

MMAN（memory manager）進程支持內存分配的自動管理。DBA僅需爲內存使用狀況肯定一個整體目標，MMAN將觀察PGA內存和SGA內存的須要，並根據須要將內存分配給會話和SGA結構，同時將內存分配總量保持在DBA設定的限制範圍內。

LREG

數據庫實例嘗試用數據庫偵聽器註冊它本身。這就容許用戶經過偵聽器鏈接數據庫。在高級環境中，例如帶有幾個實例的羣集數據庫（提供了許多服務），LREG（listener regulation process）也會用工做負載和性能信息更新偵聽器。這樣偵聽器就能夠智能地與合適的實例進行會話。在早期版本中，這個功能由PMON進程實現。在12c版本中，添加了一個專用的進程LREG來實現它。

 

ARCn

 

ARCn（archiver）進程的任務是：當LGWR將在線重作日誌文件填滿時，就將其複製到另外一個位置。此後這些歸檔的重作日誌文件能夠用於完成介質恢復。在線重作日誌用於在出線電源故障（實例停止）時「修正」數據文件，而歸檔重作日誌則不一樣，它是在出線硬盤故障時用於「修正」數據文件。若是丟失了包含數據文件/d01/oradata/ora11g/system.dbf的磁盤，能夠去找上一週的備份，恢復舊的文件副本，並要求在數據庫上應用自此次備份以後生成的全部歸檔和在線重作日誌。這樣就能使這個數據文件「遇上」數據庫中的其餘數據文件，因此咱們能夠繼續處理而不會丟失數據。

 

ARCn一般將在線重作日誌文件複製到至少兩個位置。這些位置多是本地機器上的磁盤，或者更確切地將，至少有一個位置在另外一臺機器上，以應付災難性的失敗。在許多狀況下，歸檔重作日誌文件會由另外某個進程複製到一個第三輔存設備上，如磁帶。也能夠將這些歸檔重作日誌文件發送到另外一臺機器上，應用於「備用數據庫」（standby database），這是Oracle提供的一個故障轉移選項。

RECO

RECO（recoverer process）分佈式數據庫恢復有一個很中心的任務：因爲兩段提交（two-phase commit，2PC）期間的崩潰或連接丟失等緣由，有些事務可能會保持準備狀態，這個進程就是要恢復這些事務。2PC是一種分佈式協議，容許影響多個不一樣數據庫的修改實現原子提交。它力圖在提交以前儘量地關閉分佈式失敗窗口。若是在N個數據庫中間採用2PC，其中一個數據（一般是客戶最初登陸的那個數據庫，但也不必定）將成爲協調器（coodinator）。這個站點會詢問其餘N-1個站點是否準備提交。實際上，這個站點會轉向另外這N-1個站點，問它們是否準備好提交。這N-1個站點都會返回其「準備就緒狀態」，報告爲YES或NO。若是任何一個站點投票（報告）NO，整個事務都要回滾。若是全部站點都投票YES，站點協調器就會廣播一條消息，使這N-1個站點真正完成提交（提交獲得持久地存儲）。

若是某個站點郵票YES，稱其準備好要提交，可是在此以後，而且在獲得協調器的指令真正提交以前，網絡失敗了，或者出現了另外某個錯誤，事務就會成爲一個可疑的分佈式事務（in_doubt distributed transaction）。2PC力圖限制出現這種狀況的時間窗口，可是沒法根除這種狀況。若是正好在那時（這個時間窗口內）出現一個失敗，處理事務的工做就要由RECO負責。RECO會試圖聯繫事務的協調器來發現協調的結果。在此以前，事務會保持未提交狀態。當再次到達事務協調器時，RECO可能會提交事務，也可能將事務回滾。

須要說明，若是失敗（outrage）持續很長一段時間，並且你有一些很重要的事務，能夠自行手動地提交或回滾。有事你可能想要這樣作，由於可疑的分佈式事務科能致使寫入器阻塞讀取器（Oracle中只有此時會發生「寫阻塞讀」的狀況）。你的DBA能夠通知另外一個數據庫的DBA，要求他查詢那些可疑事務的狀態。而後你的DBA再提交或回滾，而再也不由RECO完成這個任務。