跟 Inthirties學Oracle之checkpoint由來

什麼是checkpoint？

checkpoint能幹什嗎？

checkpoint是怎麼啟動並執行？

 

這是我們在瞭解檢查點概念的時候，需要理解的問題。也是我們在理解檢查點的時候，經常不能整明白的三個問題。
我們先不忙著對這三個檔案進行理解。一個事物的出現，必然有他出現的理由，checkpoint也固然如此。
大家都知道在我們的系統裡，儲存是資料的最後的歸屬之地，資料庫更是如此，只有資料落地生根的進入了物理的儲存空間裡，這個資料才算是放心的能夠儲存了，
所以如果要資料保證安全不丟失，及時的把他們放到了安心的地方就可以了，但是反觀而談，進入儲存空間勢必帶來IO，而這個IO往往帶來相對的效能上的劣
勢。所以要即保證資料的安全，有同時保證效能的最佳化，這個及時就要做到恰到好處了。萬事的兩面性就帶來了研究的快樂。這個檢查點也是來之於此的。對於
Oracle來說主要的檔案，大家都知道。無非就是控制檔案，資料檔案和重做記錄檔，此為Oracle資料庫執行個體能夠啟動並執行三個為高權重的檔案類型了。

控制檔案其是資料庫執行個體的資訊中心，資料檔案更不必談，是根本，重做記錄檔，其實也是用來保證資料庫的crash時的資料安全保證的。對於此三種檔案其
中最為常見的IO，log buffer寫入到log file，buffer
cache裡的髒資料之寫於資料檔案。其中前者是順序寫入的。從前向後不斷寫入，直至寫滿進行下一組的切換，後者與前者不同，並不是連續寫入的，是離散型
的，不同的資料需要寫入到不同的塊裡，不同的塊需要進行不同的定址，切換磁軌等操作，這裡讀也亦然，不過讀非本文說關心所在，暫不談之，log
buffer的寫入LGWR為之。當資料Commit或者Rollback之刻。LGWR將寫log buffer於Log file，我們故稱redo
log的寫入是同步之寫入。即資料生效及復原是，redo條目必是在實體儲存體上記下來的，由此crash後，執行個體能夠得以恢複。觀data，
data儲存在data file中。用時，載入到buffer cache裡，進行修改並進行訪問，但是buffer
cache中的資料不一定和data file中的一致，為何，因為上面提到了，為保證執行個體行之高效，修改了的資料(dirty
data髒資料)並不會馬上寫入到資料檔案。所以DBWR的寫入和commit以及rollback並非同步而為。如此這般，如若執行個體crash比如斷電或者shutdown abort，buffer cache裡的dirty data並不能在data file裡記錄下來，這樣豈不是資料將會丟失麼，確實，現在data file裡的資料並不和我們crash的時候一致。但是我們開啟了資料庫以後發現，已經提交的資料依然可以表現出來，不過是那些還沒有來的及提交的資料沒有叻。確實，雖然資料庫庫裡的data file裡的data不一致了，不過在startup的過程中，Oracle已經悄然為你上次的abort買單了。上面提到了redo log，這個redo log就是Oracle買單得以實現的手段了。Oracle記錄了重做的記錄條，根據重做的記錄條，把那些還沒有體現到data file裡的資料重新做過一遍，也就達到目的了。不過，Oracle怎麼知道你要做那些重做的內容，他會把所有的重做都做過麼，這樣來保證他找出來的重做條目就是我們所需的呢，這寫就是通過上面提到的checkpoint來實現的。

 

這裡累文疊字般的並沒有對我們的checkpoint介紹過多，看似介紹的更多是資料庫如果保證我們的資料在高效運行過程中的安全，實為提示大家我們提到的checkpoint並不是保證執行個體的運行狀態的，最後一句話，點明了，checkpoint目的是恢複資料庫而來的。是在恢複資料庫的時候確定恢複的條目而來的。而別無他用。checkpoint是學習Oracle裡的一個大家常覺得困難和不易理解的知識領域，如果你能夠先認知下checkpoint不過是Oracle執行個體在crash recovery裡的一個恢複過程中需要用到的手段，那麼checkpoint的學習你就已經先有所得了。

 

一錢窺豹，焉識其貌。本文僅告知checkpoint的由來，哪麼checkpoint如何來實現其目的，其又是如何在Oracle裡表現，我們在認知checkpoint中又會有哪些誤區。在後面的文章中我們再逐一道來。