完全バックアップ後にトランザクションログのバックアップサイズを縮小するにはどうすればよいですか？
SQL Server 2005インスタンスで実行するように設定された3つのメンテナンスプランがあります。
- 毎週のデータベース最適化とそれに続く完全バックアップ
- 毎日の差分バックアップ
- 1時間ごとのトランザクションログのバックアップ
1時間ごとのログバックアップは通常、数百Kbと10Mbの間で、アクティビティのレベルに応じて異なります。通常、1日の差分は週末までに約250Mbに増加し、週ごとのバックアップは約3.5です。 GB。
私が抱えている問題は、フルバックアップの前の最適化により、次のトランザクションログバックアップが、フルバックアップのサイズの2倍（この場合は8Gb）に増加してから、通常に戻ることです。
BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY以外に、そのログバックアップのサイズを減らす方法や、最適化がトランザクションログに記録されないようにする方法はありますか？
ここにいくつかの興味深い提案があります。これらはすべて、ログのバックアップがどのように機能するかについて誤解を示しているようです。ログバックアップには、前回のログバックアップ以降に生成されたすべてのトランザクションログが含まれています。ログバックアップを停止するか、毎日の完全バックアップに移動しても、ログバックアップのサイズには影響しません。トランザクションログに影響を与えるのは、ログバックアップチェーンが開始された後のログバックアップだけです。
このルールの唯一の例外は、ログバックアップチェーンが壊れている場合です（たとえば、SIMPLE復旧モデルに進み、データベーススナップショットから復帰し、BACKUP LOG WITH NO_LOG/TRUNCATE_ONLYを使用してログを切り捨てます）。この場合、最初のログバックアップ最後の完全バックアップ以降のすべてのトランザクションログが含まれます。これにより、ログバックアップチェーンが再開されます。または、ログバックアップチェーンが開始されていない場合-初めてFULLに切り替えると、最初の完全バックアップが行われるまで、一種の疑似SIMPLEリカバリモデルで動作します。
元の質問に答えるには、SIMPLEリカバリモデルを使用せずに、すべてのトランザクションログをバックアップする必要があります。実行するアクションに応じて、ログのバックアップをより頻繁に行ってサイズを小さくするか、よりターゲットを絞ったデータベースを実行できます。
実施している保守作業に関する情報を投稿していただければ、最適化のお手伝いをさせていただきます。偶然にも、インデックスの再構築を行ってから、データベースの縮小を行って、インデックスの再構築で使用したスペースを再利用していますか？
メンテナンスの発生中にデータベースで他のアクティビティがない場合は、次のことを実行できます。
- ユーザーアクティビティが停止していることを確認してください
- 最後のログバックアップを作成します（これにより、メンテナンス開始の時点まですぐに回復できます）
- sIMPLE復旧モデルに切り替える
- メンテナンスを実行-ログは各チェックポイントで切り捨てられます
- 完全復旧モデルに切り替えて、完全バックアップを実行する
- 通常通り続ける
これがお役に立てば幸いです-より多くの情報を楽しみにしています。
ありがとう
[編集：フルバックアップで後続のログバックアップのサイズを変更できるかどうかについての議論（結局できません）の後で、私は背景資料とそれを証明するスクリプトを含む包括的なブログ投稿をまとめました。 https://www.sqlskills.com/blogs/paul/misconceptions-around-the-log-and-log-backups-how-to-convince-yourself/] で確認してください。
それらを縮小することもできますが、それらは再び成長し、最終的にディスクの断片化を引き起こします。インデックスの再構築とデフラグにより、非常に大きなトランザクションログが作成されます。ポイントインタイムリカバリが必要ない場合は、シンプルリカバリモードに変更して、トランザクションログのバックアップを完全に削除できます。
最適化のためにメンテナンスプランを使用していると思いますが、特定の断片化レベルに達したときにのみインデックスデフラグを実行するスクリプトを使用するように変更し、パフォーマンスに影響を与えることはほとんどありません。これにより、はるかに小さなログが生成されます。
ちなみに、毎日の完全バックアップを優先して、毎日の差分をスキップします。
最後の質問は次のとおりです： "TRUNCATE_ONLYのBACKUP LOG以外に、そのログバックアップのサイズを減らすか、最適化がトランザクションログに記録されないようにする方法はありますか。確かに、それらは先行する完全バックアップで考慮されますか？」
いいえ、しかし、これは回避策です。その時点でそのデータベース内の唯一のアクティビティがインデックスメンテナンスジョブであることがわかっている場合は、インデックスメンテナンスを開始する前にトランザクションログのバックアップを停止できます。たとえば、一部のサーバーが土曜日の夜にある場合、ジョブスケジュールは次のようになります。
- 9:30 PM-トランザクションログバックアップが実行されます。
- 9:45 PM-トランザクションログバックアップが最後に実行されます。スケジュールは9:59に停止します。
- 10:00 PM-インデックスメンテナンスジョブが開始し、組み込みの停止が11:30の前に終了します。
- 11:30 PM-完全バックアップジョブは30分未満で開始および終了します。
- 午前12:00-トランザクションログのバックアップは15分ごとに再開されます。
つまり、午後9時45分から午後11時30分までの時点での回復機能はありませんが、パフォーマンスは向上します。
簡単な答え：毎週の最適化ジョブを変更して、よりバランスのとれた方法で夜間に実行します。つまり、日曜日の夜にテーブルa-eを再インデックス付けし、月曜日の夜にf-lを再インデックス付けします。バランスがとれていると、ログのサイズは平均で約1/6になります。もちろん、これは組み込みのssisインデックスメンテナンスジョブを使用していない場合に最適です。
これの欠点と、dbが経験する負荷に依存することの重要な点は、オプティマイザとクエリプランの再利用に大混乱をもたらすことです。
ただし、tログのサイズが週単位で重要な場合は、日ごとまたは時間ごとに分割して、その間にtログのバックアップを実行します。
バックアップとログのサイズを減らすために、サードパーティのツール（QuestのLitespeed、Red GateのSQL Backup、Hyperbac）を検討することもできます。テープを節約することで、短期間で投資を回収できます。
データベースの最適化中のさまざまな時点でトランザクションログを特別にバックアップできますか？ tログの合計サイズは同じですが、それぞれが小さくなり、何らかの形で役立つ場合があります。
よりターゲットを絞ったデータベースの最適化を行って、作成されるトランザクションを少なくできますか（誰かがこれについて言及しましたが、その影響が詳しく説明されていたとは思いません）。ある程度の断片化を許容したり、しばらくの間スペースを無駄にしたりするなど。テーブルの40％が5％だけ断片化されている場合、それらに触れないことでかなりのアクティビティを節約できます。
「最適化」にはインデックスの再構築が含まれていると考えられます。大量の更新や挿入が発生しないデータベースでは、これらのタスクを毎週実行することのみが許容される場合がありますが、データが非常に流動的である場合は、いくつかのことを実行できます。
スケジュールに余裕があり、影響が許容できる場合は、夜間にインデックスを再構築または再編成します。これらの夜間のインデックスメンテナンスタスクを実行する場合、再構築では30％以上、再編成では15〜30％の範囲で断片化されているインデックスのみを対象とします。
これらのタスクはログに記録されたトランザクションであるため、ログの増加が懸念される場合は、Paulの推奨を提唱します。インデックスメンテナンスの前に最後のトランザクションログバックアップを行い、シンプルリカバリに切り替えてからメンテナンスプロセスを実行し、フルリカバリに切り替えてからフルデータバックアップを行うとうまくいきます。
私は自分のログファイルに禅のようなアプローチをとっています。それらは希望するサイズです。彼らが私が生きている信条であるデータベース活動と比較して不十分なバックアップ実践のために異常な成長に耐えなかった限り。
任意のインデックスメンテナンスを実行するスクリプトについては、オンラインで調べてください。 Andrew Kellyは、1年ほど前にSQL Magazineで適切なものを公開しました。 SQLServerPediaにはMichelle Uffordのスクリプトがいくつかあり、SQL Magazineの最新号（2009年7月だと思います）にもこのトピックに関する完全な記事があります。ポイントは、自分に合ったものを見つけ、最小限のカスタマイズで自分のものにすることです。