一 . 進程概述

先來看一下 Oracle 11g 的架構圖。 看起來比較模糊，我已經上傳到了 csdn 的下載。 是個 pdf 文件， 2m 多。 那個看起來比較清楚。 也對每個進程做了解釋。

下載地址： Oracle 11g 架構圖 from Oracle University

http://download.csdn.net/source/2346700

進程是操作系統中的一種機制，它可執行一系列的操作步。在有些操作系統中使用作業 (JOB) 或任務 (TASK) 的術語。一個進程通常有它自己的專用存儲區。 ORACLE 進程的體系結構設計使性能最大。

ORACLE 實例有兩種類型： 單進程實例 和 多進程實例 。

單進程 ORACLE （又稱單用 ORACLE ）是一種數據庫系統，一個進程執行全部 ORACLE 代碼。由于 ORACLE 部分和客戶應用程序不能分別以進程執行，所以 ORACLE 的代碼和用戶的數據庫應用是單個進程執行。 在單進程環境下的 ORACLE 實例，僅允許一個用戶可存取。例如在 MS-DOS 上運行 ORACLE 。

多進程 ORACLE 實例 （又稱多用戶 ORACLE ）使用多個進程來執行 ORACLE 的不同部分 ，對于每一個連接的用戶都有一個進程。
在多進程系統中，進程分為兩類： 用戶進程 和 ORACLE 進程 。當一用戶運行一應用程序，如 PRO*C 程序或一個 ORACLE 工具（如 SQL*PLUS ），為用戶運行的應用建立一個用戶進程。

ORACLE 進程又分為兩類 ：服務器進程 和 后臺進程 。

服務器進程用于處理連接到該實例的用戶進程的請求 。當應用和 ORACELE 是在同一臺機器上運行，而不再通過網絡，一般將用戶進程和它相應的服務器進程組合成單個的進程，可降低系統開銷。然而，當應用和 ORACLE 運行在不同的機器上時，用戶進程經過一個分離服務器進程與 ORACLE 通信。它可執行下列任務：
1) 對應用所發出的 SQL 語句進行語法分析和執行。
2) 從磁盤（數據文件）中讀入必要的數據塊到 SGA 的共享數據庫緩沖區（該塊不在緩沖區時）。
3) 將結果返回給應用程序處理。

系統為了使性能最好和協調多個用戶，在多進程系統中使用一些附加進程， 稱為后臺進程 。在許多操作系統中， 后臺進程是在實例啟動時自動地建立 。一個 ORACLE 實例可以有許多后臺進程，但它們不是一直存在。

后臺進程有：
DBWR(Database Write) : 數據庫寫入程序
LGWR(Log Write) : 日志寫入程序
CKPT(Checkpoint) : 檢查點
SMON (System Monitor): 系統監控
PMON(Process Monitor) : 進程監控
ARCH(Archive) : 歸檔
RECO : 恢復
LCKn : 封鎖；

這是 RAC 環境啟動時 , 各個進程的啟動順序：

PMON started with pid=2, OS id=18042

DIAG started with pid=3, OS id=18044

PSP0 started with pid=4, OS id=18051

LMON started with pid=5, OS id=18053

LMD0 started with pid=6, OS id=18055

LMS0 started with pid=7, OS id=18057

MMAN started with pid=8, OS id=18061

DBW0 started with pid=9, OS id=18063

LGWR started with pid=10, OS id=18065

CKPT started with pid=11, OS id=18067

SMON started with pid=12, OS id=18069

RECO started with pid=13, OS id=18071

CJQ0 started with pid=14, OS id=18073

MMON started with pid=15, OS id=18075

MMNL started with pid=16, OS id=18077

每個后臺進程與 ORACLE 數據庫的不同部分交互。 其中 SMON 、 PMON 、 DBWn 、 CKPT 、 LGWR 是五個必須的 ORACLE 后臺進程。

二 . 進程詳細說明

1. DBWR 進程

該進程執行將緩沖區寫入數據文件，是負責緩沖存儲區管理的一個 ORACLE 后臺進程。當緩沖區中的一緩沖區被修改，它被標志為 “ 弄臟 ” ， DBWR 的主要任務是將 “ 弄臟 ” 的緩沖區寫入磁盤，使緩沖區保持 “ 干凈 ” 。由于緩沖存儲區的緩沖區填入數據庫或被用戶進程弄臟，未用的緩沖區的數目減少。當未用的緩沖區下降到很少，以致用戶進程要從磁盤讀入塊到內存存儲區時無法找到未用的緩沖區時， DBWR 將管理緩沖存儲區，使用戶進程總可得到未用的緩沖區。

ORACLE 采用 LRU （ LEAST RECENTLY USED ）算法（最近最少使用算法）保持內存中的數據塊是最近使用的，使 I/O 最小。

觸發 DBWR 進程的條件有：
1. DBWR 超時，大約 3 秒
2. 系統中沒有多余的空緩沖區來存放數據
3. CKPT 進程觸發 DBWR
在有些平臺上，一個實例可有多個 DBWR 。在這樣的實例中，一些塊可寫入一磁盤，另一些塊可寫入其它磁盤。

2. LGWR 進程

該進程將日志緩沖區寫入磁盤上的一個日志文件，它是負責管理日志緩沖區的一個 ORACLE 后臺進程。

觸發 LGWR 進程的條件有：
1. 用戶提交
2. 有 1/3 重做日志緩沖區未被寫入磁盤
3. 有大于 1M 的重做日志緩沖區未被寫入磁盤
4. 3 秒超時
5. DBWR 需要寫入的數據的 SCN 大于 LGWR 記錄的 SCN ， DBWR 觸發 LGWR 寫入。

日志緩沖區 是一個循環緩沖區。當 LGWR 將日志緩沖區的日志項寫入日志文件后，服務器進程可將新的日志項寫入到該日志緩沖區。 LGWR 通常寫得很快，可確保日志緩沖區總有空間可寫入新的日志項。

注意：有時候當需要更多的日志緩沖區時， LWGR 在一個事務提交前就將日志項寫出 ，而這些日志項僅當在以后事務提交后才永久化。

ORACLE 使用快速提交機制，當用戶發出 COMMIT 語句時，一個 COMMIT 記錄立即放入日志緩沖區，但相應的數據緩沖區改變是被延遲，直到在更有效時才將它們寫入數據文件 。當一事務提交時，被賦給一個系統修改號（ SCN ），它同事務日志項一起記錄在日志中。由于 SCN 記錄在日志中，以致在并行服務器選項配置情況下，恢復操作可以同步。

3. CKPT 進程

該進程在檢查點出現時，對全部數據文件的標題進行修改，指示該檢查點。負責在每當緩沖區高速緩存中的更改永久地記錄在數據庫中時 , 更新控制文件和數據文件中的數據庫狀態信息。

RedoLog Checkpoint 和 SCN 關系

http://blog.csdn.net/tianlesoftware/archive/2010/01/25/5251916.aspx

Redo Log 和 Checkpoint not complete

http://blog.csdn.net/tianlesoftware/archive/2009/12/01/4908066.aspx

4. SMON 進程

SMON 是 Oracle 數據庫至關重要的一個后臺進程 , 該進程實例啟動時執行實例恢復，還負責清理不再使用的臨時段 , 是一種用于庫的 “ 垃圾收集者 ” 。在具有并行服務器選項的環境下， SMON 對有故障 CPU 或實例進行實例恢復。 SMON 進程有規律地被呼醒，檢查是否需要，或者其它進程發現需要時可以被調用。

它做的工作包括如下 7 件：

（ 1 ）清理臨時表空間： 伴隨這 “ 真正 ” 的臨時表空間的出現，清理臨時表空間的雜事已經減輕了，但它還沒完全消失。例如，當建立一個索引，在創建期間分配給索引的擴展區被標志為 TEMPORARY 。如果 Create Index 會話因某些原因異常中斷， SMON 負責清理他們。其他操作創建的臨時擴展區， SMON 同樣會負責。
（ 2 ） 接合空閑空間： 如果你正使用數據字典管理表空間， SMON 負責把那些在表空間中空閑的并且互相是鄰近的 extent 接合成一個較大的空閑擴展區。這發生僅在帶有默認的 pctincrease 設置為非零的存儲子句的字典管理表空間。
（ 3 ） 把對于不可用文件的事務恢復成活動狀態： 它的角色類似在庫啟動期間。這時，因為文件不能用于恢復， SMON 恢復在實例 / 崩潰恢復期間被跳過的故障事務。例如，文件可能已經在不可用或沒裝載的磁盤上。當文件變可用了， SMON 將恢復它。
（ 4 ）執行一個 RAC 中故障節點的實例恢復： 在一個 oracle RAC 配置中，當群集中的一個庫實例失敗（例如，實例正執行的機器故障了），一些群集中的其他節點將開啟故障的實例的重做日志文件，為故障實例執行所有數據的恢復。
（ 5 ）清理 OBJ$ ： OBJ$ 是一個包含庫中幾乎每一個對象（表，索引，觸發器，視圖等等）的記錄的行級數據字典表。許多次，這兒存在的記錄代表已刪對象，或代表不在這兒的對象，在 oracle 的信賴機制中被使用。 SMON 是刪除這些不在被需要的行的進程。
（ 6 ）收縮回滾段： SMON 將執行回滾段的自動收縮到它的 optimal 尺寸，如果它被設置。
（ 7 ） “ 脫機 ” 回滾段： 對于 DBA 來，讓一個有 active 事務的回滾段，脫機或不可用，這事是可能的。 Active 事務正使用這脫機回滾段是可能的。在這情況下，回滾不是真正的脫機；它被標志為 “ 懸掛 offline” 。在后臺進程中， SMON 將周期性盡力讓它真正脫機，直到成功。

SMON 做許多其他事情，譬如存在 DBA_TAB_MONITORING 視圖中的監控統計數據的洗刷， 在 SMON_SCN_TIME 表中發現的時間戳定位信息的 SCN 的洗刷 ，等等。 SMON 在期間能消耗很多 CPU ，這應該被認為是正常的。 SMON 周期性的蘇醒（或被其他后臺進程叫醒）來執行這些管家的家庭雜事。

5. PMON 進程

用于恢復失敗的數據庫用戶的強制性進程，它先獲取失敗用戶的標識，釋放該用戶占有的所有數據庫資源。 PMON 有規律地被呼醒，檢查是否需要，或者其它進程發現需要時可以被調用。

PMON 進程負責在反常中斷的連接之后的清理工作。 例如，如果因某些原因專用服務 “ 故障 ” 或被 kill 掉， PMON 就是負責處理（恢復或回滾工作）和釋放你的資源。 PMON 將發出未提交工作的回滾，釋放鎖，和釋放分配給故障進程的 SGA 資源 。除了在異常中斷之后的清理外， PMON 監控其他 oracle 后臺進程，如果有必要（和有可能）重新啟動他們。如果共享服務或一個分配器故障（崩潰）， PMON 將插手并且重啟另一個（在清理故障進程之后）。

PMON 將觀察所有 Oracle 進程，只要合適或重啟他們或中止進程。 例如，在數據庫日志寫進程事件中， LGWR 故障，實例故障。這是一個嚴重的錯誤，最安全的處理方法就是去立即終止實例，讓正常的恢復處理數據。

PMON 為實例做的另一件事是去使用 Oracle TNS 監聽器登記。 當一個實例開啟的時候， PMON 進程投出眾所周知的端口地址，除非指向其他，來看是否監聽器正在開和運行著。眾所周知 / 默認端口是使用 1521 。

現在，如果監聽器在一些不同端口開啟會發生什么？這種情況，機制是相同的，除了監聽器地址需要被 LOCAL_LISTENER 參數明確指定。如果監聽器運行在庫實例開啟的時候， PMON 和監聽器通訊，傳到它相關參數，譬如服務器名和實例的負載度量。如果監聽器沒被開啟， PMON 將周期性的試著和它聯系來登記自己。

The background process PMON cleans up after failed processes by:
1. Rolling back the user’s current transaction
2. Releasing all currently held table or row locks
3. Freeing other resources currently reserved by the user
4. Restarts dead dispatchers

6. RECO 進程

負責在分布式數據庫環境中自動恢復那些失敗的分布式事務 , 保證分布式事務的一致性 , 在分布式事務中 , 要么同時 commit, 要么同時 rollback;

7. ARCH 進程

該進程將已填滿的在線日志文件拷貝到指定的存儲設備。當數據庫運行在歸檔模式下，歸檔進程負責在日志切換后將已經寫滿的重做日志文件復制到歸檔目標 .

8. LCKn 進程

是在具有并行服務器選件環境下使用，可多至 10 個進程（ LCK0 ， LCK1…… ， LCK9 ），用于實例間的封鎖。

9. MMAN 進程

內存管理 , 如果設定了 SGA 自動管理， MMAN 用來協調 SGA 內各組件的大小設置和大小調整。

10. MMON 進程

管理性監視器（ Manageability Monitor ）， MMON 主要用于 AWR ， ADDM 。 MMON 會從 SGA 將統計結果寫到系統表中。

MMON: The Manageability Monitor (MMON) process was introduced in 10g and is associated with the Automatic Workload Repository new features used for automatic problem detection and self-tuning. MMON writes out the required statistics for AWR on a scheduled basis.

三 . DBWR 、 CKPT 、 LGWR 進程之間的關系

將內存數據塊寫入數據文件實在是一個相當復雜的過程，在這個過程中，首先要保證安全。所謂安全，就是在寫的過程中，一旦發生實例崩潰，要有一套完整的機制能夠保證用戶已經提交的數據不會丟失；其次，在保證安全的基礎上，要盡可能的提高效率。眾所周知， I/O 操作是最昂貴的操作，所以應該盡可能的將臟數據塊收集到一定程度以后，再批量寫入磁盤中。

直觀上最簡單的解決方法就是，每當用戶提交的時候就將所改變的內存數據塊交給 DBWR ，由其寫入數據文件。這樣的話，一定能夠保證提交的數據不會丟失。但是這種方式效率最為低下，在高并發環境中，一定會引起 I/O 方面的爭用。 oracle 當然不會采用這種沒有擴展性的方式。 oracle 引入了 CKPT 和 LGWR 這兩個后臺進程，這兩個進程與 DBWR 進程互相合作，提供了既安全又高效的寫臟數據塊的解決方法。

用戶進程每次修改內存數據塊時，都會在日志緩沖區（ redo buffer ）中構造一個相應的重做條目（ redo entry ），該重做條目描述了被修改的數據塊在修改之前和修改之后的值。而 LGWR 進程則負責將這些重做條目寫入聯機日志文件。只要重做條目進入了聯機日志文件，那么數據的安全就有保障了，否則這些數據都是有安全隱患的。 LGWR 是一個必須和前臺用戶進程通信的進程。 LGWR 承擔了維護系統數據完整性的任務，它保證了數據在任何情況下都不會丟失。

LGWR 將重做條目寫入聯機日志文件的情況分兩種： 后臺寫（ background write ） 和 同步寫（ sync write ） 。

觸發后臺寫的條件 有四個：

1） 每隔三秒鐘， LGWR 啟動一次；

2） 在 DBWR 啟動時，如果發現臟數據塊所對應的重做條目還沒有寫入聯機日志文件，則 DBWR 觸發 LGWR 進程并等待 LRWR 寫完以后才會繼續；

3） 重做條目的數量達到整個日志緩沖區的 1/3 時，觸發 LGWR ；

4） 重做條目的數量達到 1MB 時，觸發 LGWR 。

而 觸發同步寫的條件 就一個：當用戶提交（ commit ）時，觸發 LGWR 。

假如 DBWR 在寫臟數據塊的過程中，突然發生實例崩潰。我們已經知道，用戶提交時， oracle 是不一定會把提交的數據塊寫入數據文件的。那么實例崩潰時，必然會有一些已經提交但是還沒有被寫入數據文件的內存數據塊丟失了。當實例再次啟動時， oracle 需要利用日志文件中記錄的重做條目在 buffer cache 中重新構造出被丟失的數據塊，從而完成前滾和回滾的工作，并將丟失的數據塊找回來。于是這里就存在一個問題，就是 oracle 在日志文件中找重做條目時，到底應該找哪些重做條目？換句話說，應該在日志文件中從哪個起點開始往后應用重做條目？注意，這里所指的日志文件可能不止一個日志文件。

因為 oracle 需要隨時預防可能的實例崩潰現象，所以 oracle 在 數據庫 的正常運行過程中，會不斷的定位這個起點，以便在不可預期的實例崩潰中能夠最有效的保護并恢復數據。同時，這個起點的選擇非常有講究。首先，這個起點不能太靠前，太靠前意味著要處理很多的重做條目，這樣會導致實例再次啟動時所進行的恢復的時間太長；其次，這個起點也不能太靠后，太靠后說明只有很少的臟數據塊沒有被寫入數據文件，也就是說前面已經有很多臟數據塊被寫入了數據文件，那也就意味著只有在 DBWR 啟動的很頻繁的情況下，才能使得 buffer cache 中所殘留的臟數據塊的數量很少。但很明顯， DBWR 啟動的越頻繁，那么所占用的寫數據文件的 I/O 就越嚴重，那么留給其他操作（比如讀取 buffer cache 中不存在的數據塊等）的 I/O 資源就越少。這顯然也是不合理的。

從這里也可以看出，這個起點實際上說明了，在日志文件中位于這個起點之前的重做條目所對應的在 buffer cache 中的臟數據塊已經被寫入了數據文件，從而在實例崩潰以后的恢復中不需要去考慮。而這個起點以后的重做條目所對應的臟數據塊實際還沒有被寫入數據文件，如果在實例崩潰以后的恢復中，需要從這個起點開始往后，依次取出日志文件中的重做條目進行恢復。考慮到目前的內存容量越來越大， buffer cache 也越來越大， buffer cache 中包含幾百萬個內存數據塊也是很正常的現象的前提下，如何才能最有效的來定位這個起點呢？

為了能夠最佳的確定這個起點， oracle 引入了名為 CKPT 的后臺進程，通常也叫作 檢查點進程（ checkpoint process ） 。這個進程與 DBWR 共同合作，從而確定這個起點。同時，這個起點也有一個專門的名字，叫做 檢查點位置（ checkpoint position ） 。

oracle 為了在檢查點的算法上更加的具有可擴展性（也就是為了能夠在巨大的 buffer cache 下依然有效工作），引入了 檢查點隊列（ checkpoint queue ） ，該隊列上串起來的都是臟數據塊所對應的 buffer header 。

DBWR 每次寫臟數據塊時，也是從檢查點隊列上掃描臟數據塊，并將這些臟數據塊實際寫入數據文件的。當寫完以后， DBWR 會將這些已經寫入數據文件的臟數據塊從檢查點隊列上摘下來。這樣即便是在巨大的 buffer cache 下工作， CKPT 也能夠快速的確定哪些臟數據塊已經被寫入了數據文件，而哪些還沒有寫入數據文件，顯然，只要在檢查點隊列上的數據塊都是還沒有寫入數據文件的臟數據塊。

為了更加有效的處理單實例和多實例（ RAC ）環境下的表空間的檢查點處理，比如將表空間設置為離線狀態或者為熱備份狀態等， oracle 還專門引入了 文件隊列（ file queue ） 。文件隊列的原理與檢查點隊列是一樣的，只不過每個數據文件會有一個文件隊列，該數據文件所對應的臟數據塊會被串在同一個文件隊列上；同時為了能夠盡量減少實例崩潰后恢復的時間， oracle 還引入了 增量檢查點（ incremental checkpoint ） ，從而增加了檢查點啟動的次數。

如果每次檢查點啟動的間隔時間過長的話，再加上內存很大，可能會使得恢復的時間過長。因為前一次檢查點啟動以后，標識出了這個起點。然后在第二次檢查點啟動的過程中， DBWR 可能已經將很多臟數據塊已經寫入了數據文件，而假如在第二次檢查點啟動之前發生實例崩潰，導致在日志文件中，所標識的起點仍然是上一次檢查點啟動時所標識的，導致 oracle 不知道這個起點以后的很多重做條目所對應的臟數據塊實際上已經寫入了數據文件，從而使得 oracle 在實例恢復時再次重復的處理一遍，效率低下，浪費時間。

上面說到了 有關 CKPT 的兩個重要的概念：檢查點隊列（包括文件隊列）和增量檢查點 。

檢查點隊列 在我們上面轉儲出來的 buffer header 里可以看到，就是類似 ckptq: [65abceb4,63bec66c] 和 fileq: [65abcfbc,63becd10] 的結構，記錄的同樣都是指向前一個 buffer header 和指向后一個 buffer header 的指針。這個隊列上面掛的也是臟數據塊對應的 buffer header 鏈表，但是它與 LRUW 鏈表不同。 檢查點隊列上的 buffer header 是按照數據塊第一次被修改的時間的先后順序來排列的 。越早修改的數據塊的 buffer header 排在越前面，同時如果一個數據塊被修改了多次的話，在該鏈表上也只出現一次。而且，檢查點隊列上的 buffer header 還記錄了臟數據塊在第一次被修改時，所對應的重做條目在重做日志文件中的地址，也就是 RBA （ Redo Block Address ）。同樣在轉儲出來的 buffer header 中可以看到類似 LRBA: [0xe9.229.0] 的結構， 這就是 RBA ， L 表示 Low ，也就是第一次被修改的時候的 RBA 。但是注意，在檢查點隊列上的 buffer header ，并不表示一定會有一個對應的 RBA ，比如控制文件重做（ controlfile redo ）就不會有相應的 RBA 。對于沒有對應 RBA 的 buffer header 來說，在檢查點隊列上始終處于最尾端，其優先級永遠比有 RBA 的臟數據塊的 buffer header 要低。 8i 以前，每個 working set 都有一個檢查點隊列以及多個文件隊列（因為一個數據文件對應一個文件隊列）；而從 8i 開始，每個 working set 都有兩個檢查點隊列，每個檢查點都會由 checkpoint queue latch 來保護。

增量檢查點 是從 8i 開始出現的，是相對于 8i 之前的完全檢查點（ complete checkpoint ）而言的。完全檢查點啟動時，會標識出 buffer cache 中所有的臟數據塊，然后啟動 DBWR 進程將這些臟數據塊寫入數據文件。 8i 之前，日志切換的時候會觸發完全檢查點。

而到了 8i 及以后，完全檢查點只有在兩種情況下才會被觸發：

1） 發出命令： alter system checkpoint ；

2） 除了 shutdown abort 以外的正常關閉數據庫。

注意， 這個時候，日志切換不會觸發完全檢查點，而是觸發增量檢查點。 8i 所引入的增量檢查點每隔三秒鐘或發生日志切換時啟動。 它啟動時只做一件事情：找出當前檢查點隊列上的第一個 buffer header ，并將該 buffer header 中所記錄的 LRBA （這個 LRBA 也就是 checkpoint position 了）記錄到控制文件中去 。如果是由日志切換所引起的增量檢查點，則還會將 checkpoint position 記錄到每個數據文件頭中。也就是說，如果這個時候發生實例崩潰， oracle 在下次啟動時，就會到控制文件中找到這個 checkpoint position 作為在日志文件中的起點，然后從這個起點開始向后，依次取出每個重做條目進行處理。

上面所描述的概念，用一句話來概括，其實就是 DBWR 負責寫檢查點隊列上的臟數據塊，而 CKPT 負責記錄當前檢查點隊列的第一個數據塊所對應的的重做條目在日志文件中的地址。 從這個意義上說，檢查點隊列比 LRUW 還要重要， LRUW 主要就是區分出哪些數據塊是臟的，不可以被重用的。而到底應該寫哪些臟數據塊，寫多少臟數據塊，則還是要到檢查點隊列上才能確定的。

我們用一個簡單的例子來描述這個過程。假設系統中發生了一系列的事務，導致日志文件如下所示：

事務號 數據文件號 block 號 行號 列 值 RBA

T1 8 25 10 1 10 101

T1 7 623 12 2 a 102

T3 8 80 56 3 b 103

T3 9 98 124 7 e 104

T5 7 623 13 3 abc 105

Commit SCN# timestamp 106

T123 8 876 322 10 89 107

這時，對應的檢查點隊列則類似如下圖六所示。我們可以看到， T1 事務最先發生，所以位于檢查點

圖六

隊列的首端，而事務 T123 最后發生，所以位于靠近尾端的地方。同時，可以看到事務 T1 和 T5 都更新了 7 號數據文件的 623 號數據塊。而在檢查點隊列上只會記錄該數據塊的第一次被更新時的 RBA ，也就是事務 T1 對應的 RBA102 ，而事務 T5 對應的 RBA105 并不會被記錄。因為根本就不需要在檢查點隊列上記錄。當 DBWR 寫數據塊的時候，在寫 RBA102 時，自然就把 RBA105 所修改的內容寫入數據文件了。日志文件中所記錄的提交標記也不會體現在檢查點隊列上，因為提交本身只是一個標記而已，不會涉及到修改數據塊。

這時，假設發生三秒鐘超時，于是增量檢查點啟動。增量檢查點會將檢查點隊列的第一個臟數據塊所對應的 RBA 記錄到控制文件中去。在這里，也就是 RBA101 會作為 checkpointposition 記錄到控制文件中。

然后， DBWR 后臺進程被某種條件觸發而啟動。 DBWR 根據一系列參數及規則，計算出應該寫的臟數據塊的數量，從而將 RBA101 到 RBA107 之間的這 5 個臟數據塊寫入數據文件，并在寫完以后將這 5 個臟數據塊從檢查點隊列上摘除，而留下了 4 個臟數據塊在檢查點隊列上。如果在寫這 5 個臟數據塊的過程中發生實例崩潰，則下次實例啟動時， oracle 會從 RBA101 開始應用日志文件中的重做條目。

圖七

而在 9i 以后，在 DBWR 寫完這 5 個臟數據塊以后，還會在日志文件中記錄所寫的臟數據塊的塊號。如下圖所示。這主要是為了在恢復時加快恢復的速度。

圖八

這時，又發生三秒鐘超時，于是增量檢查點啟動。這時它發現 checkpointposition 為 RBA109 ，于是將 RBA109 寫入控制文件。如果接著發生實例崩潰，則 oracle 在下次啟動時，就會從 RBA109 開始應用日志。

注：整理自網絡

-------------------------------------------------------------------------------------------------------

Blog ： http://blog.csdn.net/tianlesoftware

Email: dvd.dba@gmail.com

DBA1 群： 62697716( 滿 ); DBA2 群： 62697977( 滿 ) DBA3 群： 62697850( 滿 )

DBA 超級群： 63306533( 滿 ); DBA4 群： 83829929 DBA5 群： 142216823

DBA6 群： 158654907 聊天 群： 40132017 聊天 2 群： 69087192

-- 加群需要在備注說明 Oracle 表空間和數據文件的關系，否則拒絕申請

Oracle 后臺進程 說明