後臺進程和恢復：檢查點（DBWR）
DBWR進程是將DATA BUFFER中的數據寫入，磁盤數據文件，在這個過程中，首先保證安全，所謂安全，就是在寫過程中，一旦發生實例崩潰，要有一套完整的機制能夠保證用戶以及提交的數據不丟失，其次保證安全基礎上，要儘可能的提高效率，衆所周知，I/O操作是最昂貴的操作，所以應儘可能的將髒數據收集到一定程度以後在批量寫入磁盤。
最直觀，簡單的方法就是，只要用戶提交的時候將所改變的內存數據給DBWR，寫入到數據文件，這樣的話，一定能保證提交的數據不丟失，但是這種方式效率最低，在高併發環境中，頻繁離散寫效率最低，
因此oracle引入了LGWR 和 CKPT 這兩個後臺進程，這兩個進程與DBWR進程相互合作，提供了既安全又高效的寫髒數據的解決辦法，
DBWR觸發條件
-
產生檢查點
-
髒數據緩衝區達到閥值 默認 10%
3.掃描整個data buffer沒有空閒
data buffer 中包含髒的和未髒的優先寫髒數據列表 再寫未髒塊
-
timeout 超時，如果DBWR沒事做 會被每三秒喚醒一次去巡檢 寫不寫不一定
-
表級別的truncate 或 drop 也會觸發數據寫
-
修改表空間的 read only
-
做表空間的offline （離線）
-
熱備份 begin backup 命令
後臺進程和恢復：重做日誌文件和LGWR
用戶在修改日誌內存數據塊時都會在日誌緩衝區中構造一個相應的重做條目（redo entry），該redo條目描述了被修改的數據塊在修改之前和修改之後的值，而LGWR進程負責將這些redo條目寫入到聯機日誌文件，只要redo條目寫入了聯機日誌文件，那麼數據就安全了。
假如DBWR在寫髒數據塊的過程中，突然發生實例崩潰，該怎麼辦？我們已經知道，用戶提交時，oracle不一定會把提交的數據塊寫入數據文件的，那麼實例崩潰時，必然會有一些已經提交但是還沒有寫入數據文件的內存塊丟失，當實例再次啓動時，oracle需要利用日誌文件記錄的redo條目在buffer cache中重新構造出被丟失的數據塊，從而完成前滾和回滾的工作，將丟失的數據塊找回來。
這裏存在一個問題，就是oracle在日誌文件中找redo條目時，到底應該找哪些redo 條目？換句話說，應該在日誌文件中從哪個起點開始往後應用redo條目，注意這裏的日誌文件可能不止一個日誌文件，爲預防隨時可能的實例崩潰現象，所以oracle在數據庫的正常運行過程中，會不斷地定位這個起點，以便在不可預期的實例崩潰中能夠有效的保護並恢復數據，同時，這個起點的選擇非常講究，首先這個啓動不能太靠近日誌文件頭部，太靠近日誌文件頭部意味着要處理很多redo條目，這樣導致再次啓動實例時所進行恢復的時間太長；其次，這個起點不能太靠近日誌文件尾部，太靠近日誌文件尾部說明只有很少的髒數據塊沒有寫入數據文件，也就是說已經有很多髒數據塊被寫入數據文件，那就意味着只有在DBWR進程很頻繁的寫數據文件的情況下，才能使Buffer cache中所殘留的髒數據塊的數據量很少，但很明顯，DBWR寫的越頻繁，那麼佔用寫數據文件的I/O就越嚴重，那麼留給其他操作（比如讀取buffer cache中不存在的數據塊等）的I/O資源就越少，這顯然也是不合理的。
爲了能夠確定這個最佳的起點，oracle引入了CKPT進程，通常也叫做檢查點進程實現完全檢查點和增量檢查點來分別定位起點。
在重做日誌文件中記錄了由於執行事務處理和oracle服務期內部操作而對數據庫所做的更改。（事務處理是邏輯工作單元，由用戶運行的一個或多個SQL語句組成。）使用重做日誌文件時，可避免因斷電、磁盤故障等引起的系統故障而導致數據庫的數據不完整。重做日誌文件必須多路複用，才能確保在出現磁盤故障事件時不丟失其中存儲的信息。
重做日誌由重做日誌文件組組成。重做日誌文件組又由重做日誌文件和其多路複用副本組成。每個相同的副本都是該組的一個成員，每個組按編號標識。LogWriter(LGWR) 進程將重做記錄從重做日誌緩衝區寫入重做日誌組的所有成員，直至文件已填滿或請求了日誌切換操作。然後，這個進程會切換至下一組中的文件並執行寫入。重做日誌組以循環方式使用。
最佳方案提示：多路複用的重做日誌文件應儘量駐留在不同的磁盤中。
重做日誌文件：
·記錄數據庫的更改
·應多路複用以避免文件丟失
LogWrier觸發條件：
· 提交時（commit）
·Redo log buffer 達到三分之一滿時
· Redo log buffer 達到1M
· 每隔三秒寫一次
· DBWn執行寫入之前
後臺進程和恢復：檢查點（CKPT）
oracle爲檢查點進程提供了檢查點隊列，該隊列串起來的都是髒數據塊所對應的buffer header.每次DBWR寫髒數據時，也是從檢查點隊列上掃描髒數據塊，並將這些髒數據塊寫入數據文件中，當寫完以後，DBWR會將這些已經寫入數據文件的髒數據塊從檢查點隊列上摘下來。
1．檢查點隊列上的buffer header 是按照數據塊第一次被髒的時間先後順序來排列的。
2．越早修改的數據塊的buffer header排在越前面，
3．同時如果一個數據塊被修改了多次的話，在該鏈表上也只出現一次。
4．檢查點隊列裏記錄着這次的修改產生的redo 條目在redo 文件中的位置，簡稱（RBA）
5．檢查點隊列上的buffer header 還記錄了髒數據塊在第一次被修改時，所對應的重做條目在重做日誌文件中的地址，也就是LRBA(Low Redo Block Address)
6．數據塊最後一次修改的地址叫做HRBA
7．當數據塊第一次被修改時LRBA與HRBA是同一個地址，當同一個數據塊第二次修改時則更新HRBA值。
8．在檢查點隊列裏最後一個記錄的 RBA 被稱爲ON DISK RBA
概括下來其實就是 DBWn 負責寫檢查點隊列上的髒數據塊，而CKPT 負責記錄當前檢查點隊列的第一個數據庫塊所對應的重做日誌條目在日誌文件中的地址，將其寫入到控制文件中去。
後臺進程和恢復：歸檔程序 （ARCn）
ARCn是一個可選的後臺進程。但是，在丟失磁盤後恢復數據庫時，這個進程的作用至關重要。聯機重做日誌文件填滿後，oracle實例開始寫入下一個聯機重做日誌文件。從一個聯機重做日誌文件切換到另一個聯機重做日誌文件的過程稱爲日誌切換。
ARCn進程在每次進行日誌切換時都會開始對已填滿的日誌組進行備份或歸檔。它會在可以重新使用日誌之前自動歸檔重做日誌文件，因此會保留對數據庫所做的所有更改。這樣，即使磁盤驅動器損壞，也可以將數據庫恢復到故障點。
DBA 必須做出的一個重要決策是，配置數據庫在ARCHIVELOG模式下運行，還是在NOARCHIVELOG模式下運行。
1.在NOARCHIVELOG模式下，每次發生日誌切換時，都會件覆蓋聯機重做日誌文件。
2.在ARCHIVELOG模式下，必須先歸檔非活動的已填滿聯機重做日誌文件組，纔可以再次使用這些組。
注：ARCHIVELOG 模式對大多數備份策略而言是必須選擇的模式（並且極易配置）。
一個可選的後臺進程爲數據庫設置了ARCHIVELOG模式後自動歸檔聯機重做日誌文件，
保留對數據庫進行的所有更改的記錄。