完全バックアップ後にトランザクションログのバックアップサイズを縮小するにはどうすればよいですか？

Sql Server 2005インスタンスで実行するように設定された3つのメンテナンスプランがあります。

• 毎週のデータベースの最適化とその後の完全バックアップ
• 毎日の差分バックアップ
• 1時間ごとのトランザクションログバックアップ

1時間ごとのログバックアップは通常、アクティビティのレベルに応じて数百Kb〜10 Mbであり、1日の差分は通常、週末までに約250 Mbに増加し、1週間ごとのバックアップは約3.5 Gbです。

私が抱えている問題は、フルバックアップ前の最適化により、通常の状態に戻る前に、次のトランザクションログバックアップがフルバックアップ（この場合は8Gb）のサイズの2倍を超えるように見えることです。

以外にBACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY、そのログバックアップのサイズを小さくする方法、または最適化がトランザクションログにまったく記録されないようにする方法はありますか？

ここでいくつかの興味深い提案がありますが、これらはすべて、ログバックアップの仕組みについての誤解を示しているようです。ログバックアップには、その間に行われた完全バックアップまたは差分バックアップに関係なく、前回のログバックアップ以降に生成されたすべてのトランザクションログが含まれます。ログバックアップを停止したり、毎日の完全バックアップに移動しても、ログバックアップのサイズには影響しません。トランザクションログに影響するのは、ログバックアップチェーンが開始された後のログバックアップのみです。

このルールの唯一の例外は、ログバックアップチェーンが破損した場合です（たとえば、SIMPLE復旧モデルに移動し、データベーススナップショットから復帰し、BACKUP LOG WITH NO_LOG / TRUNCATE_ONLYを使用してログを切り捨てます）。その場合、最初のログバックアップ最後の完全バックアップ以降のすべてのトランザクションログが含まれます。これにより、ログバックアップチェーンが再起動されます。または、ログバックアップチェーンが開始されていない場合-初めてFULLに切り替えると、最初の完全バックアップが取得されるまで、一種の擬似SIMPLEリカバリモデルで動作します。

元の質問に答えるには、単純な復旧モデルに入らずに、すべてのトランザクションログをバックアップする必要があります。実行するアクションに応じて、より頻繁にログバックアップを実行してサイズを削減するか、よりターゲットを絞ったデータベースを実行できます。

行っているメンテナンス作業に関する情報を投稿できる場合は、それらの最適化を支援できます。インデックスの再構築に続いてデータベースの縮小を行い、インデックスの再構築に使用されたスペースを再利用しますか？

メンテナンスの実行中にデータベースに他のアクティビティがない場合は、次を実行できます。

• ユーザーのアクティビティが停止していることを確認してください
• 最終ログバックアップを取得します（これにより、メンテナンス開始時点まで回復できます）。
  • SIMPLE復旧モデルに切り替える
  • メンテナンスを実行する-ログは各チェックポイントで切り捨てられます
  • 完全復旧モデルに切り替えて、完全バックアップを取得します
  • 通常どおり続行

これがお役に立てば幸いです-詳細情報を楽しみにしています。

ありがとう

[編集：完全バックアップが後続のログバックアップのサイズを変更できるかどうかについての議論の後（不可能）、背景資料とそれを証明するスクリプトを含む包括的なブログ投稿をまとめました。https://www.sqlskills.com/blogs/paul/misconceptions-around-the-log-and-log-backups-how-to-convince-yourself/で確認してください。

それらを縮小することもできますが、それらは再び成長し、最終的にディスクの断片化を引き起こします。インデックスの再構築とデフラグにより​​、非常に大きなトランザクションログが作成されます。ポイントインタイムリカバリ機能が必要ない場合は、シンプルリカバリモードに変更し、トランザクションログのバックアップを完全に廃止できます。

最適化のためにメンテナンスプランを使用していると思いますが、特定の断片化レベルに達した場合にのみインデックスデフラグを実行するスクリプトを使用するように変更でき、パフォーマンスヒットはほとんどありません。これにより、はるかに小さなログが生成されます。

毎日の完全バックアップを優先して、毎日の差分をスキップします。

最後の質問は次のとおりです。「BACKUP LOG WITH TRUNCATE_ONLY以外に、そのログバックアップのサイズを小さくする方法、またはトランザクションログに最適化が記録されないようにする方法があります。先行するバックアップ？」

いいえ、しかし、これは回避策です。その時点でそのデータベース内の唯一のアクティビティがインデックスメンテナンスジョブであることがわかっている場合、インデックスメンテナンスを開始する前にトランザクションログのバックアップを停止できます。たとえば、土曜日の夜の私のサーバーのいくつかでは、ジョブスケジュールは次のようになります。

• 午後9時30分-トランザクションログバックアップが実行されます。
• 午後9時45分-トランザクションログバックアップが最後に実行されます。スケジュールは9:59に停止します。
• 10:00 PM-インデックスメンテナンスジョブが開始され、組み込みのストップが11:30までに終了します。
• 午後11時30分-完全バックアップジョブは30分以内に開始および終了します。
• 午前12:00-トランザクションログのバックアップは15分ごとに再開されます。

つまり、午後9時45分から午後11時30分までの間に特定の時点での回復性はありませんが、その見返りはパフォーマンスの向上です。

簡単な答え：毎週最適化ジョブを変更して、よりバランスの取れた方法で夜間に実行するようにします。つまり、日曜日の夜にae、月曜日の夜にf-lなどのテーブルのインデックスを再作成します。バランスが取れていれば、ログは平均でサイズの約1/6になります。もちろん、これは組み込みのsisインデックスメンテナンスジョブを使用していない場合に最適に機能します。

これのマイナス面は、dbが経験する負荷に依存する重要なことです。オプティマイザとクエリプランの再利用に大混乱をもたらします。

ただし、Tログのサイズが週単位である場合は、Tログを日単位または時間単位で分割し、その間にTログバックアップを実行してください。

バックアップとログのサイズを削減するために、サードパーティのツール（QuestのLitespeed、Red GateのSQL Backup、Hyperbac）を検討することもできます。彼らはテープの節約ですぐにお金を払うことができる。

「最適化」にはインデックスの再構築が含まれていると考えられます。大量の更新や挿入が発生しないデータベースでは、これらのタスクを毎週実行するだけでかまいませんが、データが非常に流動的である場合は、いくつかのことを行うことをお勧めします。

1. スケジュールが許し、影響が許容できる場合は、インデックスを毎晩再構築または再編成します。これらの夜間のインデックスメンテナンスタスクを実行する場合、再構築の場合は約30％、再編成の場合は15〜30％の範囲で断片化されたインデックスのみを対象とします。

2. これらのタスクはログに記録されたトランザクションなので、ログの増加が心配な場合は、Paulが推奨したことをお勧めします。インデックスメンテナンスの前の最終トランザクションログバックアップ、シンプルリカバリに切り替えてからメンテナンスプロセスを実行し、フルリカバリに切り替えてフルデータバックアップを行うとうまくいきます。

私は自分のログファイルに禅のようなアプローチを取ります。それは彼らが望むサイズです。彼らが私が住んでいるマントラであるデータベース活動と比較して貧弱なバックアップ慣行のために異常な成長に耐えていない限り。

任意のインデックスメンテナンスを実行するスクリプトについては、オンラインで確認してください。Andrew Kellyは、約1年前にSQL Magazineでまともなものを発表しました。SQLServerPediaにはMichelle Uffordのスクリプトがいくつかあり、SQL Magazineの最新号（2009年7月に私が信じている）にもこのトピックに関する完全な記事があります。ポイントは、あなたのためにうまくいくものを見つけて、最小限のカスタマイズで自分のものにすることです。

データベースの最適化中のさまざまな時点でトランザクションログを特別にバックアップできますか？Tログの合計サイズは同じになりますが、それぞれが小さくなり、何らかの形で役立つ可能性があります。

作成されるトランザクションが少なくなるように、よりターゲットを絞ったデータベース最適化を行うことができますか（誰かがこれについて言及しましたが、その意味が明確に説明されていません）。一定量の断片化やスペースの浪費をしばらく許容するなど。テーブルの40％が5％しか断片化されていない場合、それらに触れないことで、かなりのアクティビティを節約できます。