理解REDO LOG（1） 介質恢複和執行個體恢複的基本概念

    oracle世界，有3種資料：undo、redo和data。而redo 應"提交事務不丟失"而生的一種機制，服務於兩類情境：一是instance recovery、一是media recovery。

    instance recovery目的：當資料庫發生故障時，確保buffer cache中的資料不好丟失，保證資料庫的一致性
    media recovery    目的：當資料檔案發生故障時，能夠恢複資料

    redo是按照thread來組織的。於單一實例，只有一個THREAD；於RAC，可能存在多個THREAD。

    redo log機制是私人的：每個執行個體都有自己的log buffer。但在rac環境，redo log file是共用的。

    無論哪種恢複，第一步都是（資料檔案的狀態）借用redo資料前滾（undo資料檔案亦被前滾）直至最後一個可用的redo log或者歸檔日誌。

    再者，oracle的cache機制是以效能為導向，絕非儲存用的。為了這個目標，oracle須處理兩個問題：

    1）如何確保提交的事務不丟失？
    2）如何均衡執行個體恢複的時間？

    第一個問題：Log-Force-at-Commit機制
    commit時寫日誌，當返回commit complete時，才寫完日誌，即使返回到“Commit compl”時，突然斷電，日誌也沒有寫完。
    第二個問題：checkpoint機制
    data由server process讀上來，但並不負責寫下去，buffer cache寫操作由DBWn完成，DBWn根據workload以及是否被其他process使用來將一部分資料寫到資料檔案，這是具有隨機性的。而checkpoint機制便是對這種情況的有效補充。發生檢查點時，CKPT進程會要求DBWn將某個scn以前的所有dirty buffer寫回資料檔案。完成一次檢查點，這個scn之前的所有資料變更都已經存檔，如果此時發生故障，則這個事件以前的變更就無需考慮。