SQL Serverログファイルを圧縮すると、パフォーマンスにどのような影響がありますか？
サイズが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バックアップの後にそのスペースを再利用し、無制限に大きくなることはありません。または、
単純な復旧モデルを使用すると、通常の完全バックアップを実行するときのように、LOGファイルのサイズを気にする必要がありません。
LOGファイルの切り捨てとパフォーマンスに関する問題は、LOGファイルを増やす場合に常にパフォーマンスが低下することです（上記の引用）。リンクされたブログ投稿）：
ログを縮小すると、ログは再び大きくなります。おそらくVLF断片化を引き起こし、ログがインスタント初期化を使用できないため、ログが大きくなる間、ワークロードを確実に一時停止させます。 ..]
更新：LOGファイルの切り捨てをDATAファイルの縮小と間違えないでください。 DATAファイルの圧縮は本当に悪いです。詳細は データファイルを縮小しない理由 を参照してください。
問題が発生した場合に対処するには、毎日の完全バックアップでもログが必要です。 15分ごとにトランザクションログをバックアップします。問題は、トランザクションログをバックアップしていないことです。そのため、ログが非常に大きくなります。正しいトランザクションログバックアップを実行している場合は、トランザクションログを圧縮する必要はほとんどありません。
ログを切り捨てる前に、データベースをバックアップする必要があります。バックアップと切り捨ての間に新しいデータが挿入されないように、営業時間外に行うことをお勧めします。次に、適切なトランザクションログバックアップをセットアップして、この問題が発生しないようにします。
パフォーマンスへの影響に関しては、システムのハードウェアと使用法の詳細がわからないと、言うのは難しいでしょう。
トランザクションログはどれくらい速く成長しますか？速度が速い場合は、時間をかけて元に戻す必要があるため、ほとんど何もない状態に縮小することでパフォーマンスに影響を与えます。これは、ときどき縮小するべきではないという意味ではありませんが、最小に縮小するのではなく、サイズの問題を考える必要があります。パフォーマンスに大きな影響はありますか？おそらくそうではありませんが、サーバーの負荷（トランザクション数など）に依存します。
私が問題と思うのは、「毎日2つのフルバックアップを実行するので、データのロールフォワードに関する限り、ログは実際には必要ないはずです。」ログは、完全バックアップ間のポイントにとって非常に重要です。 1日2回でも、これが読み取り専用データベースでない限り、災害復旧用のログファイルの必要性がなくなるわけではありません（そうであれば、ログファイルが大幅に増加することはありません）。