1 什么是檢查點
數據修改操作 都是在 內存中的數據頁進行修改，每次修改后並沒有立即把這些頁面寫入磁盤，而是等到一定時期，數據庫引擎對數據庫發起 檢查點命令，這時，該命令就會創建一個已知的正常點，把當前所有在內存中已修改的頁面（臟頁）即事務日志信息從內存中寫入到磁盤，並且記錄下有關事務日志的信息。之后如果數據庫意外關閉或者崩潰，那么在恢復的過程中，數據庫引擎就不需要恢復所有事務日志，而是從 該檢查點 開始應用日志中所做的修改。
2 檢查點類型
3 檢查點的參數影響
recovery interval 針對於整個數據庫實例，默認為0，參數定義的時候，分為 0 跟 >0兩種情況。
target_recovery_time 針對於某個數據庫，默認為0，參數定義的時候，也分為0 跟 >0 兩種情況。
3.1 自動檢查點
3.1.1 什么是自動檢查點
當 target_recovery_time 為0時，檢查點類型為自動檢查點。自動檢查點的生成頻率，取決於數據庫 recovery_interval 配置值，可通過管理視圖 sys.sysconfigures查看配置值。
recovery_interval的配置值 指定 服務器實例在系統啟動期間 從最近一個檢查點之后應用日志來恢復數據庫 的最長時間，也就是當 目標恢復間隔為1分鍾時，那么數據庫就會檢查，那么數據庫就會估算，在 DB重啟恢復期間，1分鍾內能夠處理的最大日志記錄數，如果從最近一個檢查點之后到當前的日志記錄數達到了這個 值，那么數據庫就會自動發起一個檢查點命令。所以，自動檢查點之間的 命令執行時間並非是固定的，在業務高峰期，可能比較密集，而在業務的低峰期，則相對較長時間才允許一次檢查點命令。
這里需要注意三個地方：
- 並非說設置了 recovery_interval 后，數據庫的恢復時間就一定是在 recovery_interval 時間內，這個值只是給數據庫判斷 檢查點命令的執行時間使用，而非 明確為 數據庫的恢復時間。因為在系統崩潰后，恢復數據庫所需的時間，主要取決於重做崩潰時的臟頁所需的 IO 量。
- 簡單恢復模式下，在沒有延遲日志截斷的親開溝下，自動檢查點都會階段日志中沒有使用的部分。
- Also, under the simple recovery model, an automatic checkpoint is also queued if the log becomes 70 percent full. 這句話有歧義？是否是理解為，在簡單模式下，如果數據庫的日志填充不足70%，那么及時到了checkpoint的自動執行時間，也不會執行，而是等到 日志填充大於 70%才執行該指令？
3.1.2 recovery interval 設置
對於OLTP系統（少大事務跟少開始事務后遲遲沒有提交事務的情況），recovery interval 是確定恢復時間的主要因素。 但是，recovery interval 選項不影響撤消長時間運行的事務所需的時間。比如，設置的recovery interval為0，則是默認為 1分鍾的恢復間隔，但是修改數據執行了2個小時，那么，實際的恢復將長於 recovery interval。
通常情況下，默認值是最佳。但是，如果出現以下情況來，則可通過修改配置值來提高性能（建議逐漸增大該值來評估，而非突然修改較大值）：
- 在長時間運行的大事務沒有回滾時，數據庫恢復所耗費的時間通常都超過了1分鍾；
- 檢查點過於頻繁，內存數據頁寫入到磁盤影響了數據庫的IO性能
修改recovery interval配置如下：
1 #查看數據庫 recovery interval配置值 2 select * from sys.sysconfigures where comment like'%recovery%interval%' 3 4 #開啟高級選項 5 EXEC sp_configure 'show advanced options', 1; 6 GO 7 RECONFIGURE ; 8 GO 9 10 #配置 recovery interval 為兩分鍾 11 EXEC sp_configure 'recovery interval', 2 ; 12 GO 13 RECONFIGURE; 14 GO 15 16 #關閉高級選項 17 EXEC sp_configure 'show advanced options', 0; 18 GO 19 RECONFIGURE ; 20 GO
3.2 間接檢查點
SQL SERVER 2012開始引入的，它區別與自動檢查點，在於它們生效的范圍，自動檢查點是對整個數據庫實例生效，而間接檢查點只對指定的數據庫生效。
它的優點：
- 間接檢查點可以減少整體數據庫恢復時間。
- 間接檢查點使您可以通過控制 REDO 期間隨機 I/O 的開銷來可靠控制數據庫恢復時間。 這使服務器實例不超過給定數據庫的恢復時間上限（長時間運行的事務導致過多 UNDO 時間時除外）。
- 間接檢查點通過在后台不斷地將臟頁寫入磁盤來減小與檢查點有關的 I/O 蜂值。
它的缺點：
- 對於OLTP系統，配置間接檢查點后，會使用后台的寫入線程，從而增加服務器實例的總寫入負荷，可能造成性能下降
3.3 手動檢查點
通常，我們很少需要手動執行checkpoint指令，checkpoint的語法為 ：CHECKPOINT [ checkpoint_duration ]，checkpoint_duration 為完成該checkppoint所需的秒數。
正常情況下，我們不會指定checkpoint_duration 該值，而是用數據庫自動調整的檢查點持續時間，以降低對數據庫的性能影響。
因為數據庫在執行checkpoint的時候，臟頁數、修改數據的活動事務以及指定實際持續時間checkpoint_duration，都會影響資源的分配情況，假設指定了checkpoint_duration的值為50s，而正常情況下完成這個操作需要150s，那么這個時候，數據庫為了滿足指定的checkpoint_duration 50s，就會比正常情況下，分配更多的資源給該指令運行，那么就會影響到正常情況下的其他操作對資源的利用了。
3.4 內部檢查點（摘自MSDN）
內部檢查點由各種服務器組件生成，以確保磁盤映像與日志的當前狀態匹配。 生成內部檢查點以響應下列事件：
- 已經使用 ALTER DATABASE 添加或刪除了數據庫文件。
- 進行了數據庫備份。
- 創建了數據庫快照，不管 DBCC CHECK 是顯式還是內部執行。
- 執行了需要關閉數據庫的活動。 例如，AUTO_CLOSE 設置為 ON 並且關閉了數據庫的最后一個用戶連接，或者執行了需要重新啟動數據庫的數據庫選項更改。
- 通過停止 SQL Server (MSSQLSERVER) 服務停止了 SQL Server 實例。 任一操作都會在 SQL Server 實例的每個數據庫中生成一個檢查點。
使 SQL Server 故障轉移群集實例 (FCI) 脫機。