文章出處

Change the Target Recovery Time of a Database (SQL Server) 間接checkpoints flushcache flushcache-message

https://msdn.microsoft.com/en-us/library/hh403416.aspx

間接checkpoints在SQL Server2012開始引入

sql2012的target recovery time就是強制做checkpoint，強制人工干預
之前的recovery interval是大部分由sqlserver來決定何時做checkpoint，即使我們設置了recovery interval的值

默認target recovery time是0，并且數據庫會使用自動checkpoints（自動checkpoints受recovery interval 服務器選項的控制）

如果設置target recovery time大于0會引起數據庫使用間接checkpoints并建立一個數據庫的recovery time的上限

當一個長時間運行的事務造成太多undo事件的時候，數據庫的target recovery time上限是可以超越的

這個選項簡單來講就是強制控制SQL Server做checkpoint的間隔，比如設置為60秒，那么每60秒做一次checkpoint
ALTER DATABASE AdventureWorks2012 SET TARGET_RECOVERY_TIME = 60 SECONDS;
可以看到

recovery interval ：是實例級選項
TARGET_RECOVERY_TIME ：是數據庫級選項

本來SQL Server根據數據庫的一定修改量算法來進行checkpoint，現在強制按照時間間隔進行checkpoint，那么當修改量很少，并且讀多寫少的時候

強制checkpoint會帶來磁盤物理寫和磁盤的物理讀，因為物理寫占用了一定的IO，導致讀操作受到連累，如果按照數據庫的修改量算法來進行checkpoint可以

避免這種問題，修改量很少，不進行checkpoint，這時候不會影響讀操作

注意

配置了間接checkpoints的數據庫的在線事務可能會遭遇性能下降。間接checkpoints會確保內存中臟頁的數量要低于一個閥值以便數據庫還原時間在target recovery time定義的時間之內。實例級選項recovery interval剛好與數據庫級選項TARGET_RECOVERY_TIME間接checkpoints相反，它使用事務數來決定恢復時間而非臟頁數量。當間接checkpoints在一個數據庫上開啟并接收了大量的DML操作，

后臺的lazywriter進程會不斷刷寫臟頁到磁盤確保數據庫設置的recovery時間在target recovery time之內。這樣會造成額外的I/O活動，并造成性能瓶頸如果磁盤子系統已經超過了I/O閥值

安全

權限

需要數據庫的ALTER權限

SSMS

SQL Server2012

SQL Server2008

TSQL設置語法

TARGET_RECOVERY_TIME = target_recovery_time { SECONDS | MINUTES }

示例

設置AdventureWorks2012數據庫的target recovery time為60秒

ALTER DATABASE AdventureWorks2012 SET TARGET_RECOVERY_TIME = 60 SECONDS;

http://www.cnblogs.com/MYSQLZOUQI/articles/4966137.html

評估數據庫修改量，有兩種方法：
第一種：是記錄shared buffer里面的臟頁有多少，占所有buffer的多大比例；
第二種：記錄用戶事務的數據修改量是多少。如果用系統的臟頁數量或所占比例，來評估修改量，會不太準確，用戶有可能反復修改相同的頁面，臟頁不多，但實際修改量很大，這時候也是應該盡快進行checkpoint，減少恢復時間的。而通過記錄WAL日志的產生量，可以很好的評估這個修改量

間接checkpoints的弊端

當一個長時間運行的事務造成太多undo時間的時候，數據庫的target recovery time上限是可以超越的
配置了間接checkpoints的數據庫的在線事務可能會遭遇性能下降

自動檢查點實例級

間接檢查點數據庫級

https://blogs.msdn.microsoft.com/psssql/2012/06/01/how-it-works-when-is-the-flushcache-message-added-to-sql-server-error-log/

flushcache就是SQLSERVER的checkpoint操作，在sql2012開始可以通過打開跟蹤標志（3502和3504）查看checkpoint操作的IO吞吐量
Is Long Checkpoint就是當上一個周期的checkpoint還沒執行完，下一個周期的checkpoint發現上一個周期的checkpoint還沒執行完，而把flushcache-message日志打印到errorlog里
表示磁盤IO不給力，還未flush完數據

FlushCache is the SQL Server routine that performs the checkpoint operation. The following message is output to the SQL Server error log when trace flag (3504) is enabled.

    2012-05-30 02:01:56.31 spid14s     FlushCache: cleaned up 216539 bufs with 154471 writes in 69071 ms (avoided 11796 new dirty bufs) for db 6:0

    2012-05-30 02:01:56.31 spid14s                 average throughput: 24.49 MB/sec, I/O saturation: 68365, context switches 80348
    2012-05-30 02:01:56.31 spid14s                 last target outstanding: 1560, avgWriteLatency 15

Prior to SQL Server 2012 the trace flag had to be enabled in order to output the information to the SQL Server error log. (Trace flag was the only way to obtain the output.)

SQL Server 2012 adds an additional condition (is long checkpoint) to the logic. If the trace flag is enabled or the checkpoint ‘TRUE == IsLong’ the message is added to the SQL Server error log.

Is Long Checkpoint: A long checkpoint is defined as a ‘FlushCache / checkpoint’ operation on a database that has exceeded the configured recovery interval.

If your server does not have the trace flag enabled (use dbcc tracestatus(-1) to check) the message is indicating that the checkpoint process, for the indicated database, exceeded the configured recovery interval. If this is the case you should review your I/O capabilities as well as the checkpoint and recovery interval targets.

Not meeting the recovery interval target means that recovery from a crash could exceeded operational goals.

Bob Dorr – Principal SQL Server Escalation Engineer
<footer >
Tags 2008 2008 R2 Denali Engine How It Works SQL 2008 SQL 2012 SQL Denali SQL Server 2008 SQL Server 2008 R2 Troubleshooting: The DB Engine
</footer>