我正在调查与 ETL 过程中的大型日志扩展相关的问题，即使数据库设置为批量记录模式（并且它不是以伪简单但真正批量记录的方式运行）
使用 ::fn_dblog(null,null) 函数来检查事务日志操作和操作的上下文，日志扩展几乎完全取决于在 LCX_Heap 上下文上记录 LOP_FORMAT_PAGE 操作。（97% 的扩展是该操作，单次数据加载在日志中出现超过 60 万次。）
问题是， lop_format_page 做了什么/记录了 SQL 做了什么？
鉴于此，我应该能够反转逻辑并理解导致这种情况的因果链是什么，并且能够在适当的情况下更改 ETL。
我没想到很多人都遇到过这个问题，关于操作和上下文的可用详细信息很少甚至没有。
你是对的，这是非常薄的（AKA 不是！）记录。我在日志内部做了一些探索，并做了很多减少日志的工作（主要是通过确保批量插入实际上是批量完成的！）。所以我知道这可能很难追踪。
我最好的猜测是，在上下文中看到 LOP_FORMAT_PAGE 时，它正在清除一个新页面——例如，当该页面已满并且需要创建另一个条目时拆分索引页面时。因此，如果这个假设是正确的，您可能想要追踪可能导致一大堆新页面被分配的原因。
当您看到日志扩展时，您知道 ETL 中正在进行哪些操作吗？了解这种情况会有所帮助——如果可能，请将该信息添加到您的问题中。
此外，您是否能够在测试环境中运行和更改 ETL 代码？与其弄清楚这个难以理解的日志记录定义，不如通过运行 ETL 来隔离问题，同时注释掉一些步骤（或限制受影响的行数），然后查看是哪些更改使问题消失了。
我认为你和贾斯汀已经找到了答案，但这并不是那么复杂。
ETL 过程（提取、转换、加载）正在将数据加载到数据库中。自然，当页面填满时，需要在堆上分配新的页面。
我还以为LOP_FORMAT_PAGE只有格式化页面。但是，如果数组计数为 1，则它包含整页数据或包含数据（标题加记录）的页面的一部分以及从第二个数组中的页面末尾到记录的偏移量。