SQL Serverのトランザクションログをどのようにクリアしますか？

ログファイルを小さくすることは、予期しない増大が発生した場合に備えて、実際には予約する必要があります。ログファイルが再び同じサイズに拡大する場合、一時的に縮小してもあまり達成されません。これで、データベースの回復目標に応じて、これらのアクションを実行する必要があります。

まず、完全バックアップを取ります

何か問題が発生した場合にデータベースを復元できることを確認せずに、データベースに変更を加えないでください。

ポイントインタイムリカバリが必要な場合

（そして、ポイントインタイムリカバリとは、完全バックアップまたは差分バックアップ以外のものに復元できることを気にかけていることを意味します。）

おそらく、データベースはFULLにありますリカバリモード。そうでない場合は、次のことを確認してください：

ALTER DATABASE testdb SET RECOVERY FULL;

定期的に完全バックアップを取っている場合でも、ログファイルはログを実行するまで大きくなります。バックアップ-これはあなたの保護のためであり、あなたのディスクスペースを不必要に食い尽くすためではありません。リカバリの目的に応じて、これらのログバックアップを非常に頻繁に実行する必要があります。たとえば、災害が発生した場合に15分以内のデータを失う余裕があるというビジネスルールがある場合は、15分ごとにログをバックアップするジョブが必要です。これは、現在の時刻に基づいてタイムスタンプ付きのファイル名を生成するスクリプトです（ただし、メンテナンスプランなどでもこれを行うことができます。メンテナンスプランで縮小オプションを選択しないでください。ひどいです）。

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

\\backup_share\に注意してください基盤となる別のストレージデバイスを表す別のマシン上にある必要があります。これらを同じマシン（または同じ基盤ディスクを使用する別のマシン、または同じ物理ホスト上にある別のVM）にバックアップしても、マシンが故障するとデータベースが失われるため、実際には役に立ちません。 および そのバックアップ。ネットワークインフラストラクチャによっては、ローカルでバックアップしてから、バックグラウンドで別の場所に転送する方が理にかなっている場合があります。いずれの場合も、プライマリデータベースマシンからできるだけ早くそれらを削除する必要があります。

これで、定期的なログバックアップを実行したら、ログファイルをこれまでに作成されたものよりも合理的なものに縮小することが合理的であるはずです。これはではありません SHRINKFILEを実行することを意味しますログファイルが1MBになるまで何度も繰り返します。ログを頻繁にバックアップしている場合でも、発生する可能性のある同時トランザクションの合計に対応する必要があります。 SQL Serverはファイルをゼロにする必要があり（インスタントファイル初期化が有効になっている場合のデータファイルとは異なり）、ユーザートランザクションはこれが発生するまで待機する必要があるため、ログファイルの自動拡張イベントはコストがかかります。このgrow-shrink-grow-shrinkルーチンをできるだけ少なくしたいのですが、ユーザーにお金を払わせたくないのは確かです。

縮小が可能になる前に、ログを2回バックアップする必要がある場合があることに注意してください（Robertに感謝します）。

したがって、ログファイルの実用的なサイズを考え出す必要があります。ここにいる人は、システムについて詳しく知らなければ、それが何であるかを知ることはできませんが、ログファイルを頻繁に縮小していて、再び大きくなっている場合、適切な透かしは、おそらく最大の透かしよりも10〜50％高くなります。。これが200MBになり、後続の自動拡張イベントを50 MBにしたい場合は、次のようにログファイルのサイズを調整できます。

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

ログファイルが現在200MBを超えている場合は、最初にこれを実行する必要がある場合があることに注意してください。

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

ポイントインタイムリカバリを気にしない場合

これがテストデータベースであり、ポイントインタイムリカバリを気にしない場合は、データベースがSIMPLEにあることを確認する必要があります。リカバリモード。

ALTER DATABASE testdb SET RECOVERY SIMPLE;

データベースをSIMPLEに配置するリカバリモードでは、SQL Serverが成長してすべての記録を保持するのではなく、ログファイルの一部を再利用するようにします（基本的に非アクティブなトランザクションを段階的に廃止します）。トランザクション（FULLなどログをバックアップするまでリカバリは実行されます）。 CHECKPOINT イベントはログを制御するのに役立ち、CHECKPOINTの間に大量のt-logアクティビティを生成しない限り、ログが大きくなる必要がないことを確認します。 s。

次に、このログの増加が本当に異常なイベント（たとえば、毎年の春の清掃や最大のインデックスの再構築）によるものであり、通常の日常的な使用によるものではないことを絶対に確認する必要があります。ログファイルを途方もなく小さいサイズに縮小し、SQL Serverが通常のアクティビティに対応するためにログファイルを再度拡大する必要がある場合、何が得られましたか？一時的に解放したディスクスペースを利用できましたか？すぐに修正する必要がある場合は、次のコマンドを実行できます。

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO

それ以外の場合は、適切なサイズと成長率を設定します。ポイントインタイムリカバリの場合の例のように、同じコードとロジックを使用して、適切なファイルサイズを決定し、適切な自動拡張パラメータを設定できます。

やりたくないこと

TRUNCATE_ONLYを使用してログをバックアップしますオプションをクリックしてからSHRINKFILE 。 1つは、このTRUNCATE_ONLY このオプションは廃止され、現在のバージョンのSQLServerでは使用できなくなりました。次に、FULLにいる場合リカバリモデル。これによりログチェーンが破壊され、新しい完全バックアップが必要になります。
データベースをデタッチし、ログファイルを削除して、再接続します 。これがどれほど危険であるかを強調することはできません。データベースが復旧しない、疑わしいと思われる、バックアップ（バックアップがある場合）に戻らなければならないなどの可能性があります。
「データベースの縮小」オプションを使用する 。 DBCC SHRINKDATABASE また、同じことを行うための保守計画オプションは、特にログの問題の問題を解決するだけでよい場合は、悪い考えです。 DBCC SHRINKFILEを使用して、調整するファイルをターゲットにし、個別に調整しますまたはALTER DATABASE ... MODIFY FILE （上記の例）。
ログファイルを1MBに縮小します 。これは魅力的なように見えます。SQLServerを使用すると、特定のシナリオでそれを実行し、解放されるすべてのスペースを確認できるからです。データベースが読み取り専用でない限り（読み取り専用の場合は、ALTER DATABASEを使用してそのようにマークする必要があります）、これは、リカバリモデルに関係なく、ログが現在のトランザクションに対応する必要があるため、多くの不要な成長イベントにつながるだけです。そのスペースを一時的に解放して、SQL Serverがゆっくりと苦痛を伴うようにスペースを取り戻すことができるようにすることのポイントは何ですか？
2番目のログファイルを作成する 。これにより、ディスクがいっぱいになったドライブが一時的に緩和されますが、これは、バンドエイドで穿刺された肺を修復しようとするようなものです。別の潜在的な問題を追加するだけでなく、問題のあるログファイルを直接処理する必要があります。一部のトランザクションログアクティビティを別のドライブにリダイレクトする以外は、一度に1つのファイルしか使用できないため、2番目のログファイルは実際には何もしません（2番目のデータファイルとは異なります）。 Paul Randalは、複数のログファイルが後であなたを噛む可能性がある理由についても説明しています。

積極的に行動する

ログファイルを少し縮小して、それ自体が常に小さな速度で自動拡張するのではなく、適度に大きなサイズ（最大の同時トランザクションセットの合計に対応できるサイズ）に設定し、適切な自動拡張を設定しますフォールバックとして設定します。これにより、単一のトランザクションを満たすために複数回成長する必要がなくなり、通常の業務中に成長しなければならないことは比較的まれになります。

ここで考えられる最悪の設定は、1 MBの増加または10％の増加です。おかしなことに、これらはSQL Serverのデフォルトです（私はこれについて不平を言い、役に立たないように変更を求めました）-データファイルの場合は1 MB、ログファイルの場合は10％です。前者はこの時代では小さすぎ、後者は毎回より長いイベントにつながります（たとえば、ログファイルは500 MB、最初の成長は50 MB、次の成長は55 MB、次の成長は60.5 MBです）。、などなど-そして遅いI / Oで、私を信じてください、あなたは本当にこの曲線に気付くでしょう。

さらに読む

ここで止まらないでください。ログファイルの縮小について目にするアドバイスの多くは本質的に悪いものであり、場合によっては悲惨なものになる可能性もありますが、ディスク領域を解放することよりもデータの整合性を重視する人もいます。

2009年に書いたブログ投稿で、「ログファイルを縮小する方法は次のとおりです」という投稿がいくつか表示されました。

ブレントオザルが4年前に書いたブログ投稿で、SQL Server Magazineの記事に応えて、複数のリソースを指摘しています。公開されました。

t-logのメンテナンスが重要である理由と、データファイルを縮小してはならない理由を説明するPaulRandalによるブログ投稿。

Mike Walshは、ログファイルをすぐに縮小できない理由など、これらの側面のいくつかについても優れた回答をしています。