buffer cache實驗4-ckptq的工作機制與增量檢查點及fast_start_mttr_target引數

1.檢查點概念--chkpoint

檢查點是一個資料庫事件，存在的意義在於減少崩潰恢復crash recovery時間.
檢查點事件由後臺程式CKPT觸發，當檢查點發生時，CKPT通知DBWR程式將髒資料庫dirtybuffer寫出到資料檔案上，更新資料檔案頭及控制檔案上的檢查點資訊。
資料檔案頭的SCN是CHECKPOINT SCN.

檢查點工作原理：
在資料庫中，進行資料修改時，需要先將資料讀和記憶體中buffer cache,修改資料同時，ORACLE會記錄重做redo資訊用於恢復，有了重做日誌資訊存在，ORACLE不需要在事務提交時commit立刻將變化的資料寫回磁碟，因為立刻寫效率會低。重做資訊存在也為資料崩潰後，資料可以恢復。如斷電，記憶體中修改過未寫入資料檔案的資料丟失，下一次資料庫啟動時，可以通過重做日誌進行事務重演（不管是否提交），即前滾。將資料庫恢復至崩潰前狀態，然後資料庫可以開啟提供使用，之後ORACLE將未提交的事務回滾。
檢查點存在是為了縮短上述資料恢復的時間。
當檢查點發生時，此時的SCN稱為checkpoint scn,ORACLE會通知DBWR，把修改過的資料，即此checkpoint scn之前的髒資料dirty data從buffer cache寫入磁碟，寫入完成後，CKPT程式會相應更新控制檔案和資料檔案頭，記錄此檢查點資訊，標識變更。
檢查點完成後，此檢查點之前修改過後 資料都已經寫出到資料檔案，重做日誌中的相應重做記錄對於例項恢復已經無用（物理恢復有用）。
######################################################################

2.增量檢查點概念 incremental checkpoint 及CKPTQ,FILEQ

檢查點佇列，checkpoint queue,CKPTQ;

在資料庫內部，每個髒資料塊會被記錄到檢查點佇列，按LRBA（LOW RBA 第一次修改資料塊對應的redo block address，後面修改的RBA稱為HRBA）順序排列，如果一個資料塊多次修改，該資料塊在檢查點佇列上順序不變化。
非髒塊的buffer header中的CKPTQ資訊為空。
執行增量檢查點時，DBWR從檢查點佇列按照LOW RBA順序寫出，先修改的資料可以被按優先順序寫出，例項檢查點因此可以不被增進。
同時CKPT程式階段性使用輕量級控制檔案更新協議將當前最低RBA寫入控制檔案，CKPT在進行輕量級更新時，不改寫控制檔案中資料檔案中檢查點資訊以及資料檔案頭資訊，只記錄控制檔案檢查點SCN，controlfile checkpointed at scn 並根據增量檢查點寫出增進RBA資訊。
通過增量檢查點，資料庫可以將全部寫出改為增量漸進寫出，從而極大減少對於資料庫效能的影響，而檢查點佇列進一步將RBA和檢查點關聯起來，從而可以通過檢查點確定恢復的起點。

與CKPTQ相關的是：檔案檢查點佇列 file queue  FILEQ與物件佇列Obj-Q 

檔案檢查點提高了表空間檢查點TABLESPACE CHECKPOINT的效能，每個dirty buffer同時連結到CKPTQ和FILEQ，CKPTQ包含例項所有需要執行檢查點的BUFFER，FILEQ包含屬於特定檔案需要執行檢查點的BUFFER,每個檔案都包含一個檔案佇列，在執行表空間檢查點請求時使用FILEQ。--表空間OFFLINE會觸發表空間檢查點。

3.CKPT程式在增量檢查點中的作用：

CKPT程式監控著檢查點佇列的長度，當檢查點佇列長度達到一定限制時，CKPT會通知DBWR寫髒塊
CKPT會根據引數的設定和I/O的速度以及繁忙程度,計算出來一個Target rba(目標rba),DBWR會沿著檢查點佇列,將所有Target rba之前的髒塊重新整理到磁碟.當CKPT通知完DBWR Target rba後,CKPT的任務就結束了.並不會等待DBWR寫完所有的Target rba之前的髒塊.

通知DBWR寫髒塊,這是CKPT的任務之一,CKPT另一個任務,就是每3秒,檢測一次DBWR的寫進度.
檢查點佇列最前面的塊被稱為檢查點位置.DBWR是沿著檢查點佇列寫髒塊的,CKPT每3秒鐘檢視一下DBWR沿檢查點佇列寫到了哪裡,並且將這個位置設定為檢查點位置.也就是說檢查點位置之前的塊,都是已被DBWR重新整理到磁碟上的塊.
這個3秒一次檢查DBWR進度的工作,也是CKPT的一個重要的任務.CKPT每3秒一次將檢查點位置記錄進控制檔案,當然同時被記錄進控制檔案的還有'心跳'等其他資訊.

CKPT每3秒一次的工作和CKPT定期觸發DBWR,這兩項操作合一起被稱為--增量檢查點.

4.dbwr 寫CKPTQ上髒塊的方式：

在檢查點佇列中，髒塊根據按LRBA順序排列，DBWR每到一定的時機，被觸發。
硬體能力、髒塊數、Redo數三個指標，是DBWR是否寫髒塊的依據。
DBWR什麼時候（多久）判斷一次這三個值標：3s
也就是：DBWR 3秒醒來，依據三個指標判斷是否觸發------“增量檢查點寫”

5.fast_start_mttr_target與增量檢查點

一、關於FAST_START_MTTR_TARGET概念：  --此段百度哈哈

是一個加快例項恢復的引數，我們可以根據服務級別來定義一個合理的、可接受的值，該值的單位為秒。比如設定為60s，即2分鐘。
假定該值處於合理的情況之下，則一旦例項崩潰，在60s以內例項應當能夠被恢復。合理即是該值不能太大，也不能太小。太大則例項恢復所需的時間較長，太小則導致大量資料的及時寫入，增加了系統的I/O。
影響例項恢復時間長短的主要因素即是從最近檢查點位置到聯機重做日誌尾部之間的距離。距離越長則所需要的cache recovery 和undo、redo的時間越長。所以如何有效的縮短最近檢查點位置與聯機重做日誌尾部之間的距離，這正是FAST_START_MTTR_TARGET的目的。

關於檢查點的觸發條件有很多，比如日誌切換、資料庫shutdown、開始結束備份表空間等。檢查點的分類也很多，比如完全檢查點、部分檢查點、增量檢查點等。
FAST_START_MTTR_TARGET的值實際上也是觸發檢查點的一個觸發條件。當記憶體中產生的dirty buffer所需的恢復時間(estimated_mttr)如果到達FAST_START_MTTR_TARGET的指定時間，則檢查點程式被觸發。檢查點程式一旦被觸發，將通知DBWn程式將按檢查點佇列順序將髒資料寫入到資料檔案，從而縮短了最後檢查點位置與聯機重做日誌間的距離，減少了例項恢復所需的時間。

二、FAST_START_MTTR_TARGET引數的設定

9i之後（包括9i):fast_start_mttr_target：以例項恢復時間為單位（硬體能力、髒塊數、Redo數）
10G之後，fast_start_mttr_target預設值為0，即開啟自調節檢查點：self tune checkpoint ，自調節檢查點的受影響因素有：硬體能力、髒塊數、Redo數
自調節檢查點對應隱含引數：_disable_selftune_checkpointing:
_disable_selftune_checkpointing          Disable self-tune checkpointing             FALSE       
SYS@ bys3>show parameter statistics_level  --此引數為typical 或者all，再加上FAST_START_MTTR_TARGET 設定為非零值就啟用MTTR Advisory

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
statistics_level                     string      TYPICAL
SYS@ bys3>show parameter mttr
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
fast_start_mttr_target               integer     0
從alert日誌中資料庫啟動時的資訊可以發現：
[oracle@bys3 ~]$ cat alert_bys3.log |grep MTTR
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set

顯式的設定alter system set FAST_START_MTTR_TARGET=0會關閉自動調節，重啟資料庫在alter日誌中可以發現：
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set

當FAST_START_MTTR_TARGET顯示設為非零
SYS@ bys3>alter system set fast_start_mttr_target=25;
即： statistics_level引數為typical 或者all，再加上FAST_START_MTTR_TARGET 設定為非零值就啟用MTTR Advisory
此時alert日誌中不會有MTTR資訊--因為已經正常啟動MTTR Advisory

三、關於啟動MTTR Advisory時v$instance_recovery;檢視的使用： --未開啟MTTR Advisory時此檢視內容為空。

SYS@ bys3>select mttr_target_for_estimate ,dirty_limit,estd_cache_writes ,estd_cache_write_factor ,estd_total_writes ,estd_total_write_factor  from v$mttr_target_advice;
MTTR_TARGET_FOR_ESTIMATE DIRTY_LIMIT ESTD_CACHE_WRITES ESTD_CACHE_WRITE_FACTOR ESTD_TOTAL_WRITES ESTD_TOTAL_WRITE_FACTOR
------------------------ ----------- ----------------- ----------------------- ----------------- -----------------------
                      18        1067                57                       1               806                       1
                      17        1000                57                       1               806                       1
                      19        1268                57                       1               806                       1
                      20        1507                57                       1               806                       1
SYS@ bys3>select  target_mttr,estimated_mttr from v$instance_recovery;
TARGET_MTTR ESTIMATED_MTTR
----------- --------------
         20             12
--mttr_target_for_estimate有一個值為的最接近設定的目標時間20，以及由系統計算出的的target_mttr時間20
--同時也給出了幾組不同的mttr_target值及dirty_limit,cache_write,io 等來供選擇，設定合適的mttr值