SQL Server 2005 事务日志条目：LOP_Format_Page

Posted 2023-02-16

【中文标题】SQL Server 2005 事务日志条目：LOP_Format_Page

【英文标题】：SQL Server 2005 Transaction Log Entry : LOP_Format_Page

【发布时间】：2010-12-18 04:01:10

【问题描述】：

我正在调查与 ETL 过程中的大型日志扩展相关的问题，即使数据库设置为批量记录模式（并且它不是以伪简单但真正批量记录的方式运行）

使用 ::fn_dblog(null,null) 函数来检查事务日志操作和操作的上下文，日志扩展几乎完全取决于在 LCX_Heap 上下文上记录 LOP_FORMAT_PAGE 操作。 （97% 的扩展是该操作，单次数据加载在日志中出现超过 60 万次。）

问题是，lop_format_page 做了什么/记录了 SQL 做了什么？

鉴于此，我应该能够颠倒逻辑并理解导致这种情况的因果链是什么，并且能够在适当的情况下更改 ETL。

我没想到很多人都遇到过这个问题，关于操作和上下文的可用详细信息很少甚至没有。

【参考方案1】：

我认为LOP_FORMAT_PAGE 也只是格式化页面。但如果数组计数为 1，则它包含整页数据或包含数据（标题加记录）的页面的一部分以及第二个数组中从页面末尾到记录的偏移量。

【参考方案2】：

我认为你和贾斯汀已经找到了答案，但这并不是那么复杂。

ETL 过程（提取、转换、加载）正在将数据加载到数据库中。自然，随着页面填满，需要在堆上分配新的页面。

【讨论】：

情况肯定不简单 - 日志增长超过数据增长相当多，例如2 gig 的数据扩展产生了 5 gig 的日志 - 每页的行数非常高，并且这种增长的大部分是没有文档的这一操作。

【参考方案3】：

你说得对，这是非常少的（AKA 不是！）记录。我已经在日志内部进行了一些探索，并做了很多大量的日志缩减工作（主要是通过确保批量插入实际上是批量完成的！）。所以我知道这可能很难追踪。

看到上下文中使用 LOP_FORMAT_PAGE，我的最佳猜测是它正在清除一个新页面——例如，当该页面已满并且需要创建另一个条目时拆分索引页面时。因此，如果这个假设是正确的，您可能希望找出导致大量新页面被分配的原因。

当您看到日志扩展时，您知道 ETL 中正在进行哪些操作吗？了解这种情况会有所帮助——如果可能，请将该信息添加到您的问题中。

另外，您能否在测试环境中运行和更改您的 ETL 代码？与其弄清楚这个难以理解的日志记录定义，不如通过运行 ETL 并注释掉一些步骤（或限制受影响的行数）然后查看哪些更改使问题消失来隔离问题可能更容易。

【讨论】：

上下文是 LCX_Heap，所以我猜测它是在 ETL 过程中，而不是在上下文将是 LCX_Clustered 的索引过程中。堆页面不应该拆分，只是向前排，所以我认为这不是页面拆分操作/转发操作 - 但可以看到您的想法。该代码位于防火墙后面的客户端站点上，因此我无法让第一人称访问日志/控制环境 - 只能提交脚本。感觉就像 SSIS 包没有完全使用批量记录模式，但我还看不到在哪里。

嗯，我最初跳过了 LCX_Heap 部分，感谢您的纠正。是否有任何代码将聚集索引作为 ETL 的一部分删除？还是先将表创建为堆，然后再创建聚集索引？换句话说，即使最终模式都是聚集索引，ETL 中是否存在任何“瞬态堆”？或者在构建索引时使用 SORT_IN_TEMPDB 选项？还是 SELECT....INTO tempdb 表？等等——我并不是说这些都会导致问题，只是抛出一些想法。

另外，我在 SSIS 和日志增长方面有过糟糕的经历。在一种情况下，这是由于在 ETL 开始时开始的事务并包含每个操作。我通过在包步骤中设置 Transaction=NotSupported 来修复它。在另一种情况下，我没有正确配置插入任务，因此它们没有被最低限度地记录。但这些似乎都不符合您的行为，您看到的页面格式没有在日志中插入行。您也可以尝试在 ETL 代码中插入日志记录或时间戳，以便与事务日志记录相关联。

对此的最终回答是，一个异常长的备份过程意味着系统在加载期间正在备份，从而迫使日志将数据加载视为完全记录的任务。

啊，有道理。感谢您跟进解决这个谜团。