Oracle例項包括兩部分：SGA和 一組後臺程式。後臺程式執行保證資料庫執行所需的實際維護任務。例如，有一個程式為我們維護塊緩衝區快取，根據需要將塊寫出到資料檔案。另一個程式負責當線上重做日誌檔案寫滿時將它複製到一個歸檔目標。另外還有一個程式負責在異常中止程式後完成清理，等等。每個程式都專注於自己的任務，但是會與所有其他進 程協同工作。例如，負責寫日誌檔案的程式填滿一個日誌後轉向下一個日誌時，它會通知負責對填滿的日誌檔案進行歸檔的程式，告訴它有活幹了[@more@]

Oracle後臺程式

1、 PMON：程式監視器（Process Monitor）

這個程式負責在出現異常中止的連線之後完成清理。例如，如果你的專用伺服器“失敗”或者出於某種原因被撤銷，就要由PMON程式負責修正（恢復或撤銷工作），並釋放你的資源。PMON會回滾未提交的工作，並釋放為失敗程式分配的SGA資源。

除了出現異常連線後完成清理外，PMON還負責監視其他的Oracle後臺程式，並在必要時（如果可能的話）重啟這些後臺程式。如果一個共享伺服器或排程器失敗（崩潰），PMON會介入，並重啟另一個共享伺服器或排程器（對失敗程式完成清理之後）。PMON會檢視所有Oracle程式，可能重啟這些程式，也可能適當地終止例項。例如，如果資料庫日誌寫入器程式（LGWR）失敗，就最好讓例項失敗。這是一個嚴重的錯誤，最安全的做法就是立即終止例項，並根據正常的恢復來修正資料（注意，這是一種很罕見的情況，要立即報告給Oracle Support）。

PMON還會為例項做另一件事，這就是向Oracle TNS監聽器註冊這個例項。例項啟動時，PMON程式會詢問公認的埠地址（除非直接指定），來檢視是否啟動並執行了一個監聽器。Oracle使用的公認/預設埠是1521。如果此時監聽器在另外某個埠上啟動會怎麼樣呢？在這種情況下，原理是一樣的，只不過需要設定LOCAL_LISTENER引數來顯式地指定監聽器地址。如果資料庫例項啟動時有監聽器在執行，PMON會與這個監聽器通訊，並向它傳遞相關的引數，如服務名和例項的負載度量等。如果監聽器未啟動，PMON則會定期地試圖與之聯絡來註冊例項。

2、 SMON：系統監視器（System Monitor）

SMON程式要完成所有“系統級”任務。PMON感興趣的是單個的程式，而SMON與之不同，它以系統級為出發點，這是一種資料庫“垃圾收集器”。SMON所做的工作包括：

q 清理臨時空間：原先清理臨時空間這樣的雜事都要由我們來完成，隨著引入了“真正” 的臨時表空間，這個負擔已經減輕，但並不是說完全不需要清理臨時空間。例如，建立一個索引時，建立時為索引分配的區段標記為TEMPORARY。如果出於某種原因CREATE INDEX會話中止了，SMON就要負責清理。其他操作建立的臨時區段也要由SMON負責清理。

q 合併空閒空間：如果你在使用字典管理的表空間，SMON要負責取得表空間中相互連續的空閒區段，並把它們合併為一個更大的空閒區段。只有當字典管理的表空間有一個預設的儲存子句，而且pctincrease設定為一個非0值時，才會出現空閒空間的合併。

q 針對原來不可用的檔案恢復活動的事務：這類似於資料庫啟動時SMON的作用。在例項/崩潰恢復時由於某個檔案（或某些檔案）不可用，可能會跳過一些失敗的事務（即無法恢復），這些失敗事務將由SMON來恢復。例如，磁碟上的檔案可能不可用或者未裝載，當檔案確實可用時，SMON就會由此恢復事務。

q 執行RAC中失敗節點的例項恢復：在一個Oracle RAC配置中，叢集中的一個資料庫例項失敗時（例如，例項所在的主機失敗），叢集中的另外某個節點會開啟該失敗例項的重做日誌檔案，併為該失敗例項完成所有資料的恢復。

q 清理OBJ$：OBJ$是一個低階資料字典表，其中幾乎對每個物件（表、索引、觸發器、檢視等）都包含一個條目。很多情況下，有些條目表示的可能是已經刪除的物件，或者表示“not there”（不在那裡）物件（“not there”物件是Oracle依賴機制中使用的一種物件）。要由SMON程式來刪除這些不再需要的行。

q 收縮回滾段：如果有設定，SMON會自動將回滾段收縮為所設定的最佳大小。

q “離線”回滾段：DBA有可能讓一個有活動事務的回滾段離線（offline），或置為不可用。也有可能活動事務會使用離線的回滾段。在這種情況下，回滾段並沒有真正離線；它只是標記為“將要離線”。在後臺，SMON會定期嘗試真正將其置為離線，直至成功為止。

從以上介紹你應該對SMON做些什麼有所認識了。除此之外，它還會做許多其他的事情，如將DBA_TAB_MONITORING檢視中的監視統計資訊重新整理輸出，將SMON_SCN_TIME表中的SCN-時間戳對映資訊重新整理輸出，等等。隨著時間的推移，SMON程式可能會累積地佔用大量CPU時間，這應該是正常的。SMON會定期地醒來（或者被其他後臺程式喚醒），來執行這些維護工作。

3、 RECO：分散式資料庫恢復（Distributed Database Recovery）

RECO有一個很中心的任務：由於兩段提交（two-phase commit，2PC）期間的崩潰或連線丟失等原因，有些事務可能會保持準備狀態，這個程式就是要恢復這些事務。2PC是一種分散式協議，允許影響多個不同資料庫的修改實現原子提交。它力圖在提交之前儘可能地關閉分散式失敗視窗。如果在N個資料庫之間採用2PC，其中一個資料庫（通常是客戶最初登入的那個資料庫，但也不一定）將成為協調器（coordinator）。這個站點會詢問其他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完成這個任務。

4、 CKPT：檢查點程式（Checkpoint Process）

檢查點程式並不像它的名字所暗示的那樣真的建立檢查點（檢查點在第3章介紹重做日誌一節中已經討論過），建立檢查點主要是DBWn的任務。CKPT只是更新資料檔案的檔案首部，以輔助真正建立檢查點的程式（DBWn）。以前CKPT是一個可選的程式，但從8.0版本開始，這個程式總會啟動，所以，如果你在UNIX上執行一個ps命令，就肯定能看到這個程式。原先，用檢查點資訊更新資料檔案首部的工作是LGWR的任務；不過，一段時間後，隨著資料庫大小的增加以及檔案個數的增加，對LGWR來說，這個額外的工作負擔太重了。如果LGWR必須更新數十個、數百個甚至數千個檔案，等待提交事務的會話就可能必須等待太長的時間。有了CKPT，這個任務就不用LGWR操心了。

5、 DBWn：資料庫塊寫入器（Database Block Writer）

資料庫塊寫入器（DBWn）是負責將髒塊寫入磁碟的後臺程式。DBWn會寫出緩衝區快取中的髒塊，通常是為了在快取中騰出更多的空間（釋放緩衝區來讀入其他資料），或者是為了推進檢查點（將線上重做日誌檔案中的位置前移，如果出現失敗，Oracle會從這個位置開始讀取來恢復例項）。如第3章所述，Oracle切換日誌檔案時就會標記（建立）一個檢查點。Oracle需要推進檢查點，推進檢查點後，就不再需要它剛填滿的線上重做日誌檔案了。如果需要重用這個重做日誌檔案，而此時它還依賴於原來的重做日誌檔案，我們就會得到一個“檢查點未完成”訊息，而必須等待。

注意 推進日誌檔案只是導致檢查點活動的途徑之一。有一些增量檢查點由諸如FAST_START_ MTTR_TARGET之類的引數以及導致髒塊重新整理輸出到磁碟的其他觸發器控制。

可以看到，DBWn的效能可能很重要。如果它寫出塊的速度不夠快，不能很快地釋放緩衝區（可以重用來快取其他塊），就會看到Free Buffer Waits和Write Complete Waits的等待數和等待時間開始增長。

可以配置多個DBWn；實際上，可以配置多達20個DBWn（DBW0…DBW9、DBWa…DBWj）。大多數系統都只有一個資料庫塊寫入器，但是更大的多CPU系統可以利用多個塊寫入器。通常為了保持SGA中的一個大緩衝區快取“乾淨” ，將髒的（修改過的）塊重新整理輸出到磁碟，就可以利用多個DBWn來分佈工作負載。

最好的情況下，DBWn使用非同步I/O將塊寫至磁碟。採用非同步I/O，DBWn會收集一批要寫的塊，並把它們交給作業系統。DBWn並不等待作業系統真正將塊寫出；而是立即返回，並收集下一批要寫的塊。當作業系統完成寫操作時，它會非同步地通知DBWn寫操作已經完成。這樣，與所有工作都序列進行相比，DBWn可以更快地工作。在後面的“從屬程式”一節中，我們還將介紹如何使用I/O從屬程式在不支援非同步I/O的平臺或配置上模擬非同步I/O。

關於DBWn，還有最後一點需要說明。根據定義，塊寫入器程式會把塊寫出到所有磁碟，即分散在各個磁碟上；也就是說，DBWn會做大量的分散寫（scattered write）。執行一個更新時，你會修改多處儲存的索引塊，還可能修改隨機地分佈在磁碟上的資料塊。另一方面，LGWR則是向重做日誌完成大量的順序寫（sequential write）。這是一個很重要的區別，Oracle之所以不僅有一個重做日誌和LGWR程式，還有DBWn程式，其原因就在於此。分散寫比順序寫慢多了。透過在SGA中快取髒塊，並由LGWR程式完成大規模順序寫（可能重建這些髒緩衝區），這樣可以提升效能。DBWn在後臺完成它的任務（很慢），而LGWR在使用者等待時完成自己的任務（這個任務比較快），這樣我們就能得到更好的整體效能。儘管從技術上講這樣會使Oracle執行更多不必要的I/O（寫日誌以及寫資料檔案），但整體效能還是會提高。從理論上講，如果提交期間Oracle已經將已修改的塊物理地寫出到磁碟，就可以跳過寫線上重做日誌檔案。但在實際中並不是這樣：LGWR還是會把每個事務的重做資訊寫至線上重做日誌，DBWn則在後臺將資料庫塊重新整理輸出到磁碟。

6、 LGWR：日誌寫入器（Log Writer）

LGWR程式負責將SGA中重做日誌緩衝區的內容重新整理輸出到磁碟。如果滿足以下某個條件，就會做這個工作：

q 每3秒會重新整理輸出一次

q 任何事務發出一個提交時

q 重做日誌緩衝區1/3滿，或者已經包含1 MB的緩衝資料

由於這些原因，分配超大的（數百MB）重做日誌緩衝區並不實際，Oracle根本不可能完全使用這個緩衝區。日誌會透過順序寫來寫至磁碟，而不像DBWn那樣必須執行分散I/O。與向檔案的各個部分執行多個分散寫相比，像這樣大批的寫會高效得多。這也是使用LGWR和重做日誌的主要原因。透過使用順序I/O，只寫出有變化的位元組，這會提高效率；儘管可能帶來額外的I/O，但相對來講所提高的效率更為突出。提交時，Oracle可以直接將資料庫塊寫至磁碟，但是這需要對已滿的塊執行大量分散I/O，而讓LGWR順序地寫出所做的修改要比這快得多。

7、 ARCn：歸檔程式（Archive Process）

ARCn程式的任務是：當LGWR將線上重做日誌檔案填滿時，就將其複製到另一個位置。此後這些歸檔的重做日誌檔案可以用於完成介質恢復。線上重做日誌用於在出現電源故障（例項終止）時“修正”資料檔案，而歸檔重做日誌則不同，它是在出現硬碟故障時用於“修正”資料檔案。如果丟失了包含資料檔案/d01/oradata/ora10g/system.dbf的磁碟，可以去找上一週的備份，恢復舊的檔案副本，並要求在資料庫上應用自這次備份之後生成的所有歸檔和線上重做日誌。這樣就能使這個資料檔案“趕上”資料庫中的其他資料檔案，所以我們可以繼續處理而不會丟失資料。

ARCn通 常將線上重做日誌檔案複製到至少兩個位置（冗餘正是不丟失資料的關鍵所在！）。這些位置可能是本地機器上的磁碟，或者更確切地講，至少有一個位置在另一臺機器上，以應付災難性的失敗。在許多情況下，歸檔重做日誌檔案會由另外某個程式複製到一個第三輔存裝置上，如磁帶。也可以將這些歸檔重做日誌檔案傳送到另 一臺機器上，應用於“備用資料庫”（standby database），這是Oracle提供的一個故障轉移選項。稍後將討論其中涉及的程式。

8、 其他中心程式

取決於所用的Oracle特性，可能還會看到其他一些中心程式。這裡只是簡單地列出這些程式，並提供其功能的簡要描述。前面介紹的程式都是必不可少的，如果執行一個Oracle例項，就肯定會有這些程式。以下程式則是可選的，只有在利用了某個特定的特性時才會出現。下面的程式是使用ASM的資料庫例項所特有的，見第3章的討論：

q 自動儲存管理後臺（Automatic Storage Management Background，ASMB）程式：ASMB程式在使用了ASM的資料庫例項中執行。它負責與管理儲存的ASM例項通訊、向ASM例項提供更新的統計資訊，並向ASM例項提供一個“心跳”，讓ASM例項知道它還活著，而且仍在執行。

q 重新平衡(Rebalance，RBAL)程式：RBAL程式也在使用了ASM的資料庫例項中執行。向ASM磁碟組增加或去除磁碟時，RBAL程式負責處理重新平衡請求（即重新分佈負載的請求）。

q 以下程式出現在Oracle RAC 例項中。RAC是一種Oracle配置，即叢集中的多個例項可以裝載和開啟一個資料庫，其中每個例項在一個單獨的節點上執行（通常節點是一個單獨的物理計算機）。這樣，你就能有多個例項訪問（以一種全讀寫方式）同樣的一組資料庫檔案。RAC的主要目標有兩個：

q 高度可用性：利用Oracle RAC，如果叢集中的一個節點/計算機由於軟體、硬體或人為錯誤而失敗，其他節點可以繼續工作，還可以透過其他節點訪問資料庫。你也許會喪失一些計算能力，但是不會因此而無法訪問資料庫。

q 可擴縮性：無需購買更大的機器來處理越來越大的工作負載（這稱為垂直擴縮），RAC允許以另一種方式增加資源，即在叢集中增加更多的機器（稱為水平擴縮）。舉例來說，不必把你的 4 CPU機器擴縮為有8個或16個CPU，透過利用RAC，你可以選擇增加另外一個相對廉價的4 CPU機器（或多臺這樣的機器）。

以下程式是RAC環境所特有的，如果不是RAC環境，則看不到這些程式。

q 鎖監視器（Lock monitor，LMON）程式：LMON監視叢集中的所有例項，檢測是否有例項失敗。這有利於恢復失敗例項持有的全域性鎖。它還負責在例項離開或加入叢集時重新配置鎖和其他資源（例項失敗時會離開叢集，恢復為線上時又會加入叢集，或者可能有新例項實時地增加到叢集中）。

q 鎖管理器守護（Lock manager daemon，LMD）程式：LMD程式為全域性快取服務（保持塊緩衝區在例項間一致）處理鎖管理器服務請求。它主要作為代理（broker）向一個佇列發出資源請求，這個佇列由LMSn程式處理。LMD會處理全域性死鎖的檢測/解析，並監視全域性環境中的鎖超時。

q 鎖管理器伺服器（Lock manager server，LMSn）程式：前面已經提到，在一個RAC環境中，各個Oracle例項在叢集中的不同機器上執行，它們都以一種讀寫方式訪問同樣的一組資料庫檔案。為了達到這個目的，SGA塊緩衝區快取相互之間必須保持一致。這也是 LMSn程式的主要目標之一。在以前版本的Oracle並行伺服器（Oracle Parallel Server，OPS）中，這是透過ping實現的。也就是說，如果叢集中的一個節點需要塊的一個讀一致檢視，而這個塊以一種獨佔模式被另一個節點鎖定，資料的交換就要透過磁碟重新整理輸出來完成（塊被ping）。如果本來只是要讀取資料，這個操作（ping）的代價就太昂貴了。現在則不同，利用LMSn，可以在叢集的高速連線上透過非常快速的快取到快取交換來完成資料交換。每個例項可以有多達10個LMSn程式。

q 鎖（Lock，LCK0)程式：這個程式的功能與前面所述的LMD程式非常相似，但是它處理所有全域性資源的請求，而不只是資料庫塊緩衝區的請求。

q 可診斷性守護（Diagnosability daemon，DIAG）程式：DIAG只能用於RAC環境中。它負責監視例項的總體“健康情況”，並捕獲處理例項失敗時所需的資訊。