Sun*_*mar 2 sql-server-2012 transaction-log recovery-model
我真的对上面的问题感到困惑。请帮助我更多地了解热心作家。
谢谢你。
BOL 文档中提供了有关 Eager writer 过程的信息
热心写作
急切写入过程写入与最少记录的操作（例如批量插入和选择）相关联的脏数据页 。此过程允许并行进行创建和编写新页面。也就是说，调用操作不必等到整个操作完成后再将页面写入磁盘。
脏页：自从从磁盘读取或自上次检查点以来在内存中发生更改的所有页面都是脏页。当需要读取或写入页面时，它们会从磁盘带入内存。
急切写入过程不会等待 I/O 操作完成。他们总是使用异步（或重叠）I/O 并继续其他工作，稍后检查 I/O 是否成功。这允许 SQL Server 为适当的任务最大化 CPU 和 I/O 资源。
我的理解是，急切和懒惰的作者都在做同样的工作——将脏页硬化到磁盘。我的理解是正确的还是我在这里遗漏了什么？
是的，它们都写脏页，但它们不一样。关于检查点，我建议您阅读什么是检查点以及记录的内容。Checkpoint 将all脏页写入磁盘，而 Eager writer 处理写入（dirty data pages associated with minimally operations例如批量插入和选择到磁盘）。Checkpoint 还会定期扫描缓冲池。
由于交易记录最少，因此在批量记录恢复模型中没有机会进行前滚操作。
你说的是正确的，但我要引用，Kalen Delaney 将最小日志操作定义为：
只记录足以回滚事务的信息，不支持时间点恢复
在 BL 恢复模型中发生的事情只是记录了足够的信息来回滚事务，没有记录任何信息来前滚事务，Gail Shaw 在本文中清楚地表明了这一点。
如果我们以日志备份由最少记录的事务组成的情况为例，如果没有任何前滚操作，这个日志恢复怎么可能成功？
首先，您必须注意，在每次还原中，您都不需要进行前滚操作。当事务更改已被备份操作读取的页面时，前滚就会出现，并且如果该事务在备份进行时提交，则在恢复此类备份时需要前滚事务，这是通过读取事务日志来完成的。
在最少记录操作的情况下，急切写入器进程保证在事务完成之前在磁盘上硬化对扩展区/页面的更改。因此，事务日志仅包含有关批量记录操作的已提交更改的信息，因此如果需要，它可以回滚（它只会取消分配已分配的范围或页面）。由于更改已写入磁盘，因此无需前滚。