我试图了解在哪里为 SQL Server 2012 中引入的间接检查点画一条细线。
根据我的理解
SQL Server 会设置检查点以将脏页刷新到磁盘，但检查点之间的频率或时间间隔取决于许多因素。它由称为恢复间隔的服务器级别配置控制，此设置的默认值为零，这意味着在相当繁忙的系统中，SQL 服务器可以每分钟执行一次检查点，并且可以导致数据库恢复时间少于一分钟。
SQL Server 2012 引入了间接检查点——这反过来又可以让您控制单个数据库的恢复间隔。
在较高级别上，此设置似乎是一件好事，它允许通过执行更频繁的检查点而不是执行可能导致底层 IO 子系统泛滥的定期检查点来平衡磁盘 IO
现在我的问题是
a) 间接检查点是否考虑了脏缓冲区的数量而不是通常自动检查点使用的事务的数量？
b) 我一直在许多博客中发现间接检查点设置非常危险，因为
它会使您的 IO 系统非常繁忙。上述博客中的以下陈述是否属实？
Checkpoint 通常在单次写入操作中将大块数据最佳地写入磁盘，最大可达 256KB，具体取决于缓存中需要刷新到磁盘的连续脏页的数量。一旦通过将目标恢复时间设置为非零值来打开间接检查点功能，检查点写入将变成单页写入，8KB 写入。
c) 间接检查点设置是否更适合数据仓库与 OLTP 类型的工作负载？在开始利用间接检查点之前，您会考虑哪些 SQL 数据库场景？
更新（2016 年 4 月 14 日）：
来自SQL 2016 – 它只是运行得更快： Microsoft 客户服务和支持 (CSS) SQL 支持的官方团队 Web 日志上的间接检查点默认值：
间接检查点是否考虑脏缓冲区的数量而不是通常自动检查点使用的事务的数量？
一旦我们设置了 target_recovery_time，SQL Server 就会在内部计算目标脏缓冲区阈值。当事务记录在事务日志中时，脏页列表会跟踪事务修改的 LSN 和脏缓冲区。因此，对于间接检查点，来自每个事务的脏缓冲区以及 LSN 都被跟踪。
Recovery Writer（2012 年的新后台进程）定期轮询脏页列表，如果它发现缓冲池中的脏页数量大于目标脏缓冲区阈值，它会刷新脏缓冲区并向前移动 minLSN。
间接检查点设置是否更适合数据仓库与 OLTP 类型的工作负载？
从BOL开始，为间接检查点配置的数据库上的在线事务工作负载可能会出现性能下降。这是因为间接检查点使用的后台编写器有时会增加服务器实例的总写入负载。
在开始利用间接检查点之前，您会考虑哪些 SQL 数据库场景？
这取决于许多因素，因为每个环境在硬件、内存、发生的事务等方面都不同。我建议您测试并双重测试此特殊功能，因为它可能对您有帮助，否则可能会对您的工作负载造成不利影响，并可能危及您的数据库。默认情况下，目标恢复时间设置为零，这意味着，如果您已经对其进行了全面测试并且您可以接受其行为，请更改它......
优点 ：
它可能会缩短数据库恢复时间 它可能会减少检查点 I/O，因为它会在后台连续将页面写入磁盘
缺点：
在 OLTP 工作负载中，它可以通过在后台向磁盘连续写入页面来增加服务器上的整体写入，这可能会降低性能。
参考：
在 SQL Server 2012 中按数据库设置间接检查点
检查点如何工作以及记录什么？