データベースが一括ログモードに設定されているにもかかわらず、ETLプロセス中の大規模なログ拡張に関連する問題を調査しています（疑似シンプルでは実行されていませんが、実際には一括ログに記録されています）
:: fn_dblog（null、null）関数を使用して、トランザクションログ操作と操作のコンテキストを調べると、ログの拡張は、LCX_HeapコンテキストでのLOP_FORMAT_PAGE操作のログにほぼ完全に依存します。（拡張の97％はその操作であり、1回のデータロードで60万回以上ログに表示されます。）
問題は、SQLが行ったlop_format_pageの実行/記録は何ですか？
それを考えると、論理を逆にして、原因/結果の連鎖がこれをもたらすものであるかを理解し、必要に応じてETLを変更できるはずです。
多くの人がこれに出くわしたとは思っていません。操作とコンテキストに関する利用可能な詳細のレベルはごくわずかです。
これは非常に薄く（別名ではありません！）文書化されていることは間違いありません。私はログの内部を少し調べて、多くのログ削減作業を行いました (ほとんどの場合、一括挿入が実際に一括で行われることを確認することによって!)。したがって、これを追跡するのは難しい場合があることを私は知っています。
私の推測では、LOP_FORMAT_PAGE がコンテキストで使用されているのを見て、それが新しいページをクリアしているということです。したがって、この仮定が正しければ、大量の新しいページが割り当てられる原因を突き止めたいと思うかもしれません。
ログの展開を見ながら、ETL でどの操作が行われているか知っていますか? このコンテキストを理解すると役に立ちます。可能であれば、その情報を質問に追加してください。
また、テスト環境で ETL コードを実行および変更できますか? この不可解なログ レコードの定義を理解する代わりに、いくつかの手順をコメント アウト (または影響を受ける行の数を制限) しながら ETL を実行し、どの変更によって問題が解消されるかを確認することで、問題を特定しやすくなる場合があります。
あなたとジャスティンは答えにたどり着いていると思いますが、それほど複雑ではありません。
ETL プロセス (抽出、変換、ロード) がデータをデータベースにロードしています。当然、ページがいっぱいになると、新しいページをヒープに割り当てる必要があります。