サイズが2GBのデータファイルを持つSQL Server 2008データベースがありますが、ログファイルは8GBを超えています。2008年以前のデータベースでは、「バックアップログ」とTRUNCATE_ONLYオプションを使用できましたが、2008以降のデータベースでは使用できなくなりました。
ログファイルを切り捨てるスクリプトがあります。
USE [MyDatabase]
GO
ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC shrinkfile('MyDatabase_log', 1)
ALTER DATABASE [MyDatabase] SET RECOVERY FULL WITH NO_WAIT
GOこれはログファイルを完全に切り捨てますが、私の質問は次のとおりです。これはパフォーマンスに影響しますか？
私は毎日2回のフルバックアップを実行しているため、データのロールフォワードに関する限り、ログは実際には必要ありません。
回答:
Paul S. Randalによる適切なトランザクションログサイズ管理の重要性を読むことをお勧めします。
本質は、トランザクションログ処理を行うための本当に良い方法は2つしかないことです。
通常のLOGファイルバックアップを使用すると、LOGファイルは各LOGバックアップの後にそのスペースを再利用し、無期限に成長しません。
SIMPLE復旧モデルを使用すると、通常の完全バックアップを行うので、ログファイルのサイズを気にする必要はありません。
何に関するログファイルの切り捨てとパフォーマンスは、ログファイルが（上記のリンクのブログ記事からの引用）に増加させる場合は、必ずパフォーマンスヒットを取得することです。
ログを縮小すると、再び大きくなります-VLFフラグメンテーションが発生する可能性があり、ログがインスタント初期化を使用できないため、ログが大きくなるとワークロードが確実に一時停止します[...]
更新： LOGファイルの切り捨てをDATAファイルの縮小と間違えないでください。データファイルの縮小は本当に悪いです。詳細については、データファイルを圧縮しない理由を参照してください。
最初に[はい]をクリックします。問題が発生した場合に回復する場合は、毎日の完全バックアップでもログが必要です。15分ごとにトランザクションログをバックアップします。問題は、トランザクションログをバックアップしていないことです。そのため、ログが非常に大きくなります。正しいトランザクションログバックアップを実行している場合、トランザクションログを縮小する必要はほとんどありません。
ログを切り捨てる前に、データベースをバックアップする必要があります。バックアップと切り捨ての間に新しいデータが挿入されないように、営業時間外に行うことをお勧めします。その後、適切なトランザクションログバックアップを設定して、この問題が二度と起こらないようにします。
システムのハードウェアと使用法の詳細を知らなくても、パフォーマンスに影響を与えることについては、言うのは難しいでしょう。
トランザクションログはどのくらい速く成長しますか？かなり速い場合は、成長に時間を費やす必要があるため、パフォーマンスをほとんどゼロに縮小することでパフォーマンスに影響します。これは、時々縮小しないことを意味するものではありませんが、単に最小に縮小するのではなく、サイズの問題について考える必要があります。パフォーマンスは大打撃を受けますか？おそらくそうではありませんが、サーバーの負荷（トランザクション数など）に依存します。
問題があると思うことの1つは、「毎日2回の完全バックアップを実行しているため、データのロールフォワードに関する限り、ログは実際には必要ないはずです」です。ログは、完全バックアップ間のポイントにとって非常に重要です。これが読み取り専用データベースでない限り、1日2回でも災害復旧用のログファイルの必要性が排除されるわけではありません（ただし、ログファイルが大幅に増加することはありません）。