我正在研究与ETL过程中的大型日志扩展有关的问题，即使数据库是以批量记录模式设置的（并且它没有在psuedo中运行，但实际上是批量记录）
使用:: fn_dblog（null，null）函数来检查事务日志操作和操作的上下文，日志扩展几乎完全取决于在LCX_Heap上下文中记录LOP_FORMAT_PAGE操作。 （扩展的97％是该操作，对于单个数据加载，在日志中出现超过600k次。）
问题是，SQL执行/记录的lop_format_page是做什么的？
鉴于此，我应该能够扭转逻辑并理解导致这种情况的因果链是什么，并且如果合适的话能够改变ETL。
我并不期待很多人遇到过这个问题，关于运营和背景的可用细节水平很少甚至没有。
答案 0 :(得分：3)
你说这是非常薄的（AKA没有！）是正确的。我在日志中做了一些小事，并完成了很多的日志减少工作（主要是通过确保批量插入实际上是批量完成的！）。所以我知道追踪可能很有挑战性。
我最好的猜测是，在上下文中看到LOP_FORMAT_PAGE后，它正在清除一个新页面 - 例如，当该页面已满并且需要创建另一个条目时拆分索引页面时。因此，如果这个假设是正确的，您可能想要追踪可能导致一大堆新页面被分配的内容。
当您看到日志扩展时，您是否知道ETL中正在进行哪些操作？理解这种情况会很有帮助 - 如果可能的话，请将这些信息添加到您的问题中。
此外，您是否能够在测试环境中运行和更改您的ETL代码？通过运行ETL同时注释掉一些步骤（或限制受影响的行数），然后查看哪个更改使问题消失，可能更容易找出问题，而不是找出这个不可思议的日志记录定义。
答案 1 :(得分：0)
我认为你和贾斯汀都在回答，但并不是那么复杂。
ETL过程（Extract，transform，load）正在将数据加载到db中。当然，随着页面填满，需要在堆上分配新的页面。
答案 2 :(得分：0)
我认为LOP_FORMAT_PAGE也仅格式化页面。但是，如果数组的计数为1，则它要么包含整页数据，要么包含具有数据的页的一部分（页眉和记录），并从第二个数组的页末开始偏移记录。