ORACLE CheckpointQueue和增量檢查點

&nbsp; &nbsp;

&nbsp;檢查點的主要目的是以對資料庫的日常操作影響最小的方式重新整理髒塊。髒塊不斷的産生，如何将髒塊重新整理到磁盤中去呢？在8i之前，Oracle定期的鎖住所有的修改操作，将Buffer&nbsp;cache中的所有髒塊刷到磁盤，這種重新整理髒塊的方式被稱為完全檢查點，這極大的影響了效率，從9i之後隻有當關閉資料庫時才會發生完全檢查點。

&nbsp;

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;從8i開始，Oracle增加了增量檢查點的概念，增量檢查點的主要作用就是定期的重新整理一部分髒塊。将髒塊一次重新整理完是不合理的，因為髒塊不斷産生，沒有窮盡。像完全檢查點那樣停止使用者所有的修改操作，将髒塊重新整理完再繼續，這絕對會極大的影響性能。所有增量檢查點的一次重新整理部分塊是髒塊問題的最好解決辦法。那麼，每次重新整理時，都重新整理那些塊呢？根據統計研究，根據塊變髒的順序，每次重新整理那些最早髒的塊，這種方式最為合理。為了實作這一點，Oracle在Buffer&nbsp;cache中又建立了一個連結清單，就是檢查點隊列。每個塊在它變髒時，會被連結到檢查點隊列的末尾。就好像排隊一樣，9:00來的人站在第一位，9:05來的人排第二位，以後每來一個人都站在隊伍的末尾，這個隊伍就是按來到的時間順序排列的一個隊列。檢查點隊列就是這樣，塊在變髒時會被鍊到末尾。是以檢查點隊列是按塊變髒的時間順序，将塊排成了一個隊列。

&nbsp; &nbsp; &nbsp;如上圖，檢查點隊列中的每一節點，都指向一個髒塊。檢查點隊列每個節點中的資訊其實非常少，就是記錄對應塊在Buffer&nbsp;cache中的位址，髒塊對應的重做記錄在日志檔案中的位置，另外還有前一個節點、後一個節點的位址。檢查點隊列還有LRU、髒LRU，這些都是雙向連結清單。雙向連結清單就是在節點中記錄前、後兩個節點的位址。

&nbsp;檢查點隊列頭部的塊是最早變髒的，是以，Oracle會定期喚醒DBWn從檢查點隊列頭開始，沿着檢查點隊列的順序，重新整理髒塊。在重新整理髒塊的同時，仍可以不斷的有新的髒塊被連結到檢查點隊列的尾部。這個定期喚醒DBWn重新整理髒塊的操作，Oracle就稱為增量檢查點。

&nbsp;如上圖，1、2、3号節點所指向的髒塊已經被重新整理為幹淨塊。同時，又有兩個塊變髒，它們被連結到了檢查點隊列的末尾，它們是9号、10号節點。

&nbsp;檢查點隊列的頭，又被稱為檢查點位置，Checkpoint&nbsp;postion，這些名稱我們不必從字面上去了解。總之，檢查點位置就是檢查點隊列頭。檢查點隊列頭節點（也就是檢查點位置）的資訊，Oracle會頻繁的将它記錄到控制檔案中，而且會很頻繁的記錄。一般是每隔三秒，有一個專門的程序CKPT，會将檢查點位置記錄進控制檔案。

&nbsp;如上圖，目前的檢查點位置是檢查點隊列的1号節點。又一個三秒到了，CKPT程序啟動，将新的檢查點位置記入控制檔案：

&nbsp;新的檢查點位置是4号節點，它對應目前變髒時間最早的髒塊。1、2、3号節點已經從檢查點隊列中摘除了。因為它們對應的髒塊已經不髒了。一般來說，控制檔案中的檢查點位置之後的塊都是髒塊。但是有時也例外，因檢查點位置每三秒才會更新一次，就像上圖，1、2、3号節點對應的髒塊已經被重新整理過了，但是由于三秒間隔沒到，檢查點位置還是指向1号節點。隻有當三秒到後，檢查點位置才會被更新到4号節點上。

&nbsp;關于檢查點隊列、檢查點位置我們先說到這裡，在全面的介紹什麼是增量檢查點之前，我們先說一下檢查點隊列的一個重要作用。

&nbsp; &nbsp; &nbsp;讓我們先來總結一下使用者修改塊時，Oracle内部都發生了什麼：

&nbsp;1．如果塊不在Buffer&nbsp;cache，将塊讀入Buffer&nbsp;cache

&nbsp;2．先生成重做記錄，并記入日志緩存，在使用者送出時寫到日志檔案中

&nbsp;3．在Buffer&nbsp;cache中修改塊

&nbsp;4．在Buffer&nbsp;cache中設定塊的髒标志位，标志塊變成髒塊，同時在檢查點隊列末尾增加一個新節點，記錄這個新髒塊的資訊，資訊包括：髒塊在Buffer&nbsp;cache中的位置，在步驟2時生成的與此髒塊對應的重做記錄位置。

&nbsp;5．使用者送出後，将相應的重做記錄從重做緩存寫入日志檔案。

&nbsp; &nbsp; &nbsp;我現在将日志補充到上面的圖中：

&nbsp;就像上圖，檢查點隊列的每個節點，都儲存有髒塊的位址和髒塊對應的重做記錄的編号。髒塊在Buffer&nbsp;cache中的位置是随機的，使用者不一定修改那個塊。但重做記錄是順序生成的，就和檢查點隊列的排列順序一樣。因為，它們都是當塊被修改而變髒時産生的。塊A先被修改，塊A的重做記錄就排在前面，塊B後被修改，塊B對應的重做記錄會被排在塊A對應的重做記錄的後面。和它們在檢查點中的順序是一樣。每當資料庫因異外而當機，比如異常當機、斷電等等，Buffer&nbsp;cache中有許多髒塊沒來的及寫到磁盤上。以圖為例，比如說現在斷電了，現在磁盤上還有7個髒塊，它們裡面有使用者修改過的資料，Oracle已經将回報資訊“你的修改完成”發送給使用者，使用者也以為他們的修改完成了，将為一直儲存到資料庫中。但是，斷然的斷電，令這幾個髒塊中的資料丢失了，它們沒來得及寫到磁盤上。

&nbsp;&nbsp;

&nbsp;&nbsp;Oracle如何解決這個問題呢？很簡單，當資料庫重新啟動時，Oracle隻需從控制檔案中讀出檢查點位置，檢查點位置中記錄有重做記錄編号，根據此編号，Oracle可以很快的定位到日志檔案中的重做記錄n，它讀出重做記錄n中的重做資料，将使用者的修改操作重制到資料庫。接着，Oracle讀取重做記錄n+1中的重做資料，重制使用者修改，這個過程将沿着日志流的順序，一直進行下去，直擋最後一條重做記錄，在上圖的例子中，最後一條重做記錄是第n+6條。這個過程完成後，使用者所有的修改又都被重制了，一點都不會丢失。隻要你的日志檔案是完整，日志流是完整的，就一點資訊都不會丢失。

&nbsp;有人可能會有一個問題，重做記錄在生成後，也是先被送進重做緩存，再由重做緩存寫往日志檔案。這樣的機制下，一定會有某些重做記錄在沒來的及寫到日志檔案中時，資料庫突然當機，而造成這些重做記錄丢失。這樣，這些重做記錄所對應的髒塊，将得不到恢複。使用者還是會丢失一些資料。

&nbsp;這種情況的确會發生，但丢失的都是沒用的資訊。為什麼這麼說的。Oracle會在使用者每次發出送出指令時，将事務所修改髒塊對應的重做記錄寫進日志檔案，隻有當這個操作完成時，使用者才會收到“送出完成”，這樣的資訊，對于一個完整的事務，當使用者看到送出完成後，也就意味着所對應的重做記錄一定被寫到了日志檔案中，即使發生異常當機，它也是絕對可以恢複。而當使用者沒有送出，或沒來得及送出，資料庫就崩潰了，那麼事務就是不完整的，這個事務必須被復原，它根本用不着恢複。對于這樣不完整的事務，它對應的重做記錄有可能丢失，但這無所謂了，因為不完整的事務根本不需要恢複。也就是說，隻有使用者的事務送出了，使用者的修改一定不會丢失。不過這還有一個前提，就是日志檔案千萬不能損壞，DBA所要做的就是要保證日志檔案不能損壞。DBA可以使用RAID1這樣的磁盤鏡像技術，或者多元備份日志檔案，等等，這個我們在前面章節中已經講過了的。

&nbsp; &nbsp; &nbsp;我們上面所講到的這種恢複，是自動進行的，并且不需要DBA參與，它被稱之為執行個體恢複。

&nbsp;檢查點隊列與增量檢查點的作用我們已經說的差不多了，它們的主要目的就是讓DBWn沿檢查點隊列的順序重新整理髒塊。還有，就是執行個體恢複。

&nbsp; &nbsp; &nbsp;下面我們來讨論一下增量檢查點的設定。

&nbsp;這裡所說的檢查點設定，主要指增量檢查點頻繁的設定。注意增量檢查點隻是一個名詞，不必按字面的意義去了解它。增量檢查點發生時，Oracle會喚醒DBWn沿着檢查點隊列寫髒塊，這就是增量檢查點。那麼到底多長時間一次發生一次增量檢查點呢？這個增量檢查點的頻率是非常重要的，它基本上控制着DBWn多長時間去重新整理一次髒塊。DBWn活動的太頻繁，會影響資料庫的整體性能，如果DBWn活動太不頻繁，又會使髒塊擠壓太多，這同樣也會影響性能。而且，如果出現異常崩潰，需要執行個體恢複，髒塊越多，執行個體恢複越慢。。在9i之前DBA主要靠間隔時間等方式來設定增量檢查點的頻率，比如可以讓Oracle每10分鐘發生一次增量檢查點。如果這個數字設定不合适，對資料庫性能的影響是很大的。而且有可能造成執行個體恢複時間過長。在9i之後，特别是到了10g中，檢查點已經相當的智能化了，很少會成為I/O問題的原兇。9i中設定fast_start_mttr_target參數為你所期望的執行個體恢複時間，系統将自動控制增量檢查點的頻率。比如，你希望執行個體恢複可以在5分鐘内完成，你可以将此參數設定為300，也就是300稱。

&nbsp;如果此參數設定的值超出了硬體實際的限制，比如你将它設定為60，你期望無論在任何情況下，資料庫都可以在1分鐘内完成執行個體恢複，但根據資料庫的髒塊生成速度、儲存設備的寫性能，1分鐘内根本無法完成執行個體恢複。這時候Oracle會自動設定合适的fast_start_mttr_target參數值，我們可以在參數檔案中看到修正後的參數值，也可以在V$instance_recovery視圖中的Target_mttr列中看到實際的值。例如：

&nbsp; &nbsp; &nbsp;（舉個例子）

&nbsp;我們不能将這個值設定的太小，因為執行個體恢複必競隻是偶然現象。如果為了讓執行個體恢複盡快完成，而設定fast_start_mttr_target為很小的值，那麼DBWn将活動的很頻繁，這會造成性能問題的。為了避免使用者設定不合理的增量檢查點頻率，在10G中，如果将fast_start_mttr_target設定為0，Oracle将根據産生髒塊的速度、存貯硬體的性能自動調節檢查點的頻率，盡量使檢查點頻率不成為I/O問題的原兇。

&nbsp;檢查點的主要任務就是催促DBWn重新整理髒塊，如果DBWn重新整理髒塊時的等待事件太多，就說明髒塊太多、儲存設備的寫速度太慢，或者就是增量檢查點的頻率太高了，或太低了。DBWn寫髒塊的等待事件是Db&nbsp;file&nbsp;parallel&nbsp;write。如果你的增量檢查點頻率很低，你發現了此事件，在排除了儲存設備寫性能的問題後，你應該将增量檢查點頻率設定的高一些。反之，如果你的增量檢查點頻率本身很高，出現了Db&nbsp;file&nbsp;parallel&nbsp;write事件，這說明檢查點頻率太高了。

&nbsp;除它之外，還有一個和DBWn、增量檢查眯有關的等待事件，它是Write&nbsp;complete&nbsp;waits事件，目前台程序要修改DBWn正要成批寫的塊中的若幹個塊時，就會有此等待事件，這個事件是前台程序再等待DBWn寫完成。這個等待事太多，說明了儲存設備寫性能有問題，或者增量檢查點太頻率了。

&nbsp; &nbsp; &nbsp;我們可以V$instance_recovery中看到有關檢查點的很多資訊：

&nbsp;Estimated_mttr列如果太大，說明檢查點不夠頻繁，同時也說明髒塊産生的太多。同時在V$sysstat資料視圖中，還有兩個資料background&nbsp;checkpoints&nbsp;started、background&nbsp;checkpoints&nbsp;completed，前面的一個是背景程序檢查點開始次數，後一個是背景程序檢查點完成次數。背景程序檢查點的意義，其實就是增量檢查點。隻有增量檢查點是由背景程序觸發的。如果你用Alter&nbsp;system&nbsp;checkpoing指令讓系統完成完全檢查點，這叫做前台檢查點與增量檢查點無關，是不會被記入這兩個資料了。如果這兩個值經常相差一些，比如檢查點的開始次數比完成次數大的不至1，這說明有太多次檢查點開始，但沒有及時完成。這說明檢查點太頻繁或檢查點完成的太慢。

&nbsp;（舉例，大量的産生髒塊、日志檔案比較小5MB，日志檔案頻率的切換而觸發檢查點，同時檢視一下等待事件）

&nbsp;檢查點的問題大多數情況下其實都是DBWn寫I/O的問題，&nbsp;DBWn寫髒塊的等待事件是Db&nbsp;file&nbsp;parallel&nbsp;write，還有Write&nbsp;complete&nbsp;waits等待事件，是目前台程序要修改DBWn正要成批寫的塊中的若幹個塊時，就會有此等待事件，這個事件是前台程序再等待DBWn寫完成。這個等待事太多，也說明了DBWn有問題。

&nbsp;注意，對于資料檔案的I/O問題，除了等待事件外，我們還可以用上幾節講過了V$filestat視圖幫助确定問題。）

ORACLE CheckpointQueue和增量檢查點

繼續閱讀

set define off關閉替代變量功能

報錯：'mysql' 不是内部或外部指令，也不是可運作的程式或批處理檔案。

Linxu常用指令技巧彙總

ERROR 1 (HY000): Can't create/write to file '/tmp/#sql_4188_1.MYI' (Errcode: 28)

艱難安裝LDAP,SSL認證

《Linux指令行與Shell腳本程式設計大全第2版.布盧姆》pdf

MySQL的4種隔離級别？出現問題

XX系統實施過程問題總結

無元件上傳圖檔到資料庫中，最完整解決方案

【MySQL資料庫】資料庫索引事務1.索引2.事務

neo4j之cypher使用文檔

NOSQL安全攻擊

mybatis_入門程式Mybatis入門

登入plsql 報錯 the account is locked --使用者被鎖

SequoiaDB巨杉資料庫C++驅動概述

Oracle 批量查詢傳入List 傳回List