トランザクションログはSQL Serverで自動的に縮小されますか？

10

SQL ServerデータベースがSIMPLEモードの場合、トランザクションログのバックカップを気にする必要はありません。ただし、SIMPLEモードでは、FULLモードと同様にトランザクションログが大きくなるようです。ある時点で自動的に切り捨てられますか？それとも手動で切り詰める必要がありますか？

— ジュララ
ソース

19

自動的に切り捨てられますが、縮小することは非常に異なります。切り捨ては、ログスペースを再利用するために再利用し、縮小すると、ファイルサイズが物理的に小さくなり、スペースがOSに解放されます。ログが現在のサイズに成長している場合は、縮小すると再び増加する可能性があります。

私はあなたのシステムにとっての典型的で最大のログ使用量を把握することを勧めます。以下のクエリ（私のものではなく、Glen Berrys DMVスクリプトからブーストされたもの）は手動で実行することも、エージェントジョブを介して出力をテーブルにキャプチャすることもできます。ログを1週間ほどテーブルに記録すると、典型的な使用状況の画像が得られます。さらに重要なのは、プロセスが原因でログが予想以上に大きくなっている場合です。

SELECT 
     db.[name] AS [Database Name]
   , db.recovery_model_desc AS [Recovery Model]
   , db.log_reuse_wait_desc AS [Log Reuse Wait Description]
   , ls.cntr_value AS [Log Size (KB)]
   , lu.cntr_value AS [Log Used (KB)]
   , CAST(
        CAST(lu.cntr_value AS FLOAT) / CAST(ls.cntr_value AS FLOAT) 
        AS DECIMAL(18,2)
     ) * 100 AS [Log Used %]
   , db.[compatibility_level] AS [DB Compatibility Level]
   , db.page_verify_option_desc AS [Page Verify Option]
   , db.is_auto_create_stats_on, db.is_auto_update_stats_on
   , db.is_auto_update_stats_async_on, db.is_parameterization_forced
   , db.snapshot_isolation_state_desc, db.is_read_committed_snapshot_on
FROM sys.databases AS db
   INNER JOIN sys.dm_os_performance_counters AS lu 
     ON db.name = lu.instance_name
   INNER JOIN sys.dm_os_performance_counters AS ls 
     ON db.name = ls.instance_name
WHERE lu.counter_name LIKE N'Log File(s) Used Size (KB)%' 
   AND ls.counter_name LIKE N'Log File(s) Size (KB)%'
   AND ls.cntr_value > 0 
OPTION (RECOMPILE);

トランザクションログの切り捨ては、ログの切り捨てが発生するタイミングと理由の両方を示します。

ログレコードがトランザクションログから削除されなかった場合、物理ログファイルが使用できるすべてのディスク領域が最終的にいっぱいになります。ログの切り捨てにより、論理ログのスペースが自動的に解放され、トランザクションログで再利用できます。

ログの切り捨てを遅延させる可能性のある要因は、ログが切り捨てられず、予想よりも大きくなる理由を理解するのに役立ちます。

— マークストーリースミス
ソース

4

いやいや

縮小または切り詰められません（物理的なLDFの意味では、論理的に行われます）。
それはあなたがそれを縮小しないようにそれがあるサイズである必要があります

縮小すると、再び拡大し、断片化されたファイルになります

— GBN
ソース

0

前述のように、自動的には縮小しません。ただし、一部のゴミはクリーンアップされます。

その理由は、完全復旧モデルでは、SQLにポイントインタイムリカバリのtlogバックアップを実行するように指示しているため、データベースに対して行われたすべてのトランザクションの記録が保持されるためです。

ポイント・イン・タイム・リカバリーが必要であることを伝えているので、フルバックアップとtlogバックアップを行う必要があります。tlogバックアップを完了すると、ログの内容（末尾のほかに）がフラッシュされ、最初からやり直されます。

これらのファイルをコンテナーと考えると役立つ場合があります。

私の提案は、tlogが大きくなり、管理できなくなった場合は、完全バックアップをカットすることです。切り替えSIMPLEは、モデルを回復し、SHRINK TLOGファイルを。完全復旧モデルに切り替えて、フラグメンテーションメンテナンスを実行します*。他の人が投稿したように、これはベストプラクティスではなく、高レベルの断片化につながります。

その後、バックアップ体制を計画して開始します。

* インデックスの再構築/再編成操作とディスクレベルの最適化。これはログの保守の一部ではありません。Tログは、バックアップすることによって保守します。容量に近づくと成長するコンテナです。再構築/再編成は、ドライブの大量使用につながる不適切なログ管理からの回復に役立ちます。

— ライアン
ソース