web-dev-qa-db-ja.com

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

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

sql-serversql-server-2008backuptransactionshrink
10
jrara

自動的に切り捨てられますが、縮小することは非常に異なります。切り捨てはログスペースを再利用するために再利用し、縮小するとファイルサイズが物理的に小さくなり、スペースを解放して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);

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

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

ログの切り捨てを遅延させる可能性のある要因 は、ログが切り捨てられず、予想より大きくなる可能性がある理由を理解するのに役立つリファレンスです。

19
Mark Storey-Smith

いやいや

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

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

4
gbn

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

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

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

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

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

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

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

0
Ryan