Disk的checkpoint主要是將記憶體中的dirty pages和交易紀錄資訊寫入disk，
所以dirty pages的數量和checkpoint作業時間為線性關係，SQL Server會自動調整checkpoint作業頻率(預設60秒)，
這樣做是要降低其他應用程式所受到的效能影響，如果減少頻率，則會拉長完成時間，
增加頻率，則會影響效能(資料庫一般I/O活動會大幅增加)，
如果沒有特別理由，建議由SQL Server自行決定checkpoint頻率。
SQL Server以前在設計checkpoint作業，因當時物理硬碟限制，所以主要避免硬碟讀寫頭隨機搜尋(不像現在普遍都採用SSD)，
在記憶體中一發現dirty page，先將每個dirty page放入queue中，
flush處理則會盡可能將queue中pages(依照page id)寫入單一block，讓這些pages在disk盡可能緊密且連續，
自動觸發checkpoint公式:
(Log records * fixed time to recover) > configured recovery interval=Enqueue automatic checkpoint
Note:SQL7.0~SQL2008預設dirty pages:16，SQL2012增加為32，SQL2016目前為128。
From Microsoft。
SQL2012引入間接checkpoint(SQL2016所有DB預設都採用間接checkpoint)，
SQL Server依然需要追蹤有那些dirty pages，但結合以前設計優點並新增一條程序叫” PrepareToDirty”(間接checkpoint就是沿用該程序)。
SQL Server會建立一個dirty page manager，裡面會有partition list(依照LSN排序)來存放所有dirty pages list。
每個資料庫的TARGET_RECOVERY_TIME是用來觸發checkpoint作業(計算有多少dirty pages和Log records的redo時間)，
間接checkpoint會取得目前的partition lists，list中的page都會依照ID正向排序，都準備就緒時，
會把這些page盡可能都寫入單一block(延續以前設計)，
這時不影響dirty page manager查詢作業，因為dirty page manager還可以繼續存放其他空的partition list，
同時也可以避免list發生衝突，而寫入disk後，則會清空相關partition list並讓下一次checkpoint作業繼續使用。
間接checkpoint建議使用在記憶體足夠的系統上，
這也是為什麼SQL2016預設使用，MS宣稱當你建立一個4TB資料庫，
傳統自動checkpoint可能需要數分鐘，但間接checkpoint只需數秒即可完成(只建立250 BUF結構)，
也可以縮短回復時間。
For In-Memory table
記憶體和硬碟資料表的自動checkpoint有點不同(因為兩種資料保存方式不同)，
針對schema_and_data需求，checkpoint需要定期執行，以推進交易紀錄的使用紀錄，
來達到記憶體資料表還原或復原到上一個成功的checkpoint，
且當交易紀錄檔案大於1.5GB(包含硬碟和記憶體的交易紀錄)才會觸發(當然你也可以手動觸發checkpoint)，
所以當你資料庫含有記憶體資料表時，執行備份交易紀錄檔案，
不一定可以截斷交易紀錄並重複使用空間，除非你達到1.5GB的門檻。
另外針對一些大系統也有一些特例，當你滿足下列三個條件時
1.Server超過16 logical processors
2.Server超過128GB記憶體
3.Server的subIOsystem超過 200MB/sec指標
這時SQL Server將自動啟用Large checkpoint for memory-optimized tables，這有以下2點行為改變
1.data files從128 MB變為 1GB，delta file從16 MB變為128MB
2.自動checkpoint觸發門檻從1.5GB變為12GB
我當時測試RTO卻非常緩慢，後來我才知道滿足三個條件後，SQL SERVER預設啟用Large checkpoint，
因為checkpoint門檻變為12GB，這可能大幅增加復原時間(如果中間不幸發生意外)，
之後SQL Server team決定關閉預設啟用Large checkpoint，
我也有順便寫封Email來確認當時我遇到的問題，下面是來自microsoft的Jos de Bruijn回覆和我(擷取部分)
參考
Checkpoint Operation for Memory-Optimized Tables
SQL 2016 – It Just Runs Faster: Indirect Checkpoint Default
Database Checkpoints (SQL Server)
Checkpoint process for memory-optimized tables in SQL 2016 and implications on the log
[SQL Server]In-Memory Table檔案群組和檔案規劃考量
SQL Server 2016 Memory-Optimized Tables – The Checkpoint operation