インデックスの再編成中にトランザクションログがいっぱいになるのを防ぐ方法は？
トランザクションログのサイズを50GBに事前に割り当てた複数のマシンがあります。私が再編成しようとしているテーブルのサイズは55〜60 GBですが、継続的に増加します。私が再編成したい主な理由は、スペースを再利用することであり、それによるパフォーマンス上の利点は追加のボーナスです。
テーブルの断片化レベルは30〜35％です。これらのマシンの一部では、「トランザクションログがいっぱいです」エラーが発生し、再編成が失敗します。トランザクションログのサイズは最大48GBに達します。これに対抗する良い方法は何ですか？自動インクリメントがオンになっていないため、これを行うのは気が進まない。
ログサイズを大きくして値を増やすことはできますが、将来的にテーブルサイズが大きくなると、値が不十分になる可能性があります。また、ログサイズを均等に大きくしようとすると、スペースを再利用するために再編成を行う目的に反します。これに効果的に対抗するにはどうすればよいですか？データの損失は許容できないため、バルクモードの使用はオプションではありません。
REORGANIZE（ALTER INDEX ... REORGANIZEなど）は非常に高速な操作（まあ、ほとんど...）であり、少量のログを必要とし、いつでも中断して後で再開することができ、内部で （小さなバッチトランザクション ：
最適化は一連の短いトランザクションとして実行されるため、ログバックアップが頻繁に行われる場合、または復旧モデルの設定がSIMPLEの場合、大きなログは不要です。
rebuildについて話していませんか？インデックスREBUILDは遅く、高価であり、膨大な量のログを消費します（オフラインでなく、ログに記録できない場合 最小ログ 、オンライン再構築は最小ログに記録できません）、単一の巨大なトランザクションであり、すべての作業を失う。
あなたは再構築を行っているようですが、これは非常によく考えられた理由がない限り、実行すべきではない本当に例外的な操作です。どんなスペースを取り戻したいですか？ DBCC CLEANTABLE 処理しませんか？テーブルの物理構造を確認しましたか、それは論理構造からずれていませんか（詳細は 内部のSQL Serverテーブルの列 を参照してください）？
本当にテーブルを再構築する必要がある場合は、箇条書きをかじって必要なログを割り当てるしかありません。自動成長させないでください。プロセスの速度が低下するだけです。テーブルのサイズの2.5倍に事前に拡大します。
テーブルがパーティション化されている場合は、一度に1つのパーティションをオフラインで再構築（および再編成）できます。オンライン再構築は、テーブルレベル全体でのみ実行できます。
ベストプラクティス は約REORGANIZEで約30％の断片化を下回り、REBUILDを上回ります。単に、REBUILDはクリーンなコピーを作成し、REORGANIZEはその場でコピーします。
あなたが実際に何をしているかを確認してください：あなたは両方を行っているメンテナンスプランを持っていませんか？
より大きなテーブルでは（50GBテーブルがそこに到達しています）このルールに従えば、REORGANIZEがすべてのトランザクションログ領域を消費することを確認しました。頻繁ではない：特定の負荷パターンを持つ1つのシステムのみ。 REORGANIZEは、ログが拡張してすべてのディスク領域を消費するまで実行されました。
問題なく、代わりにREBUILDに切り替えましたが、25％未満の断片化は無視しました。これは私たちにとってよりうまくいきました：あなたがそれがあなたのために働くかどうかを確認する必要があります。
REBUILDは、本番環境ではREORGANIZEよりもパフォーマンスに影響を与える可能性がありますが、ONLINEオプション（Enterprise Editionが必要）で軽減できる場合があります。
以前にこの問題がありました。
- 大きなデータベースと小さなログドライブがあります。 （さまざまな理由で）再編成したい。
- フラグメント化された大きなテーブルでこれを試みると、ログドライブがいっぱいになるまでログがいっぱいになり、その後コマンドが異常終了します。
- シンプルモードの場合、他のトランザクションは次のチェックポイントでログがクリアされるまで失敗する可能性があり、フルモードの場合、他のトランザクションは次のログバックアップまで失敗する可能性があります。停止！
- フルモードの場合、ログのバックアップ頻度を増やしますが、再編成は暗黙的なトランザクションで行われるため問題を回避するのに役立ちません。トランザクションは、トランザクションが完了するか、中止されるか、停止されるまでクリアされません。
- そして、あなたは本当にそれを完全に実行するために再編成したいです。
再編成を中止すると、中断したところから続行できるため、ロールバックするのではなく、トランザクションをコミットするだけです。
これがあなたのやることです。少し長いですが簡単です。
- ログファイルのサイズを比較的大きくしますが、最大サイズにはしません。基本的には、有用な作業を行うために十分なスペースを残し、さらに小さな成長が発生した場合に備えて、通常の操作が停止しないようにします。
- インデックスの再編成を実行するジョブを作成します（「再編成」）。
パフォーマンス条件でエージェントWMIアラート（「リリーフバルブの再編成」）を作成します。
- オブジェクト：SQLServer：Databases
- カウンター：使用済みログの割合
- インスタンス：（大きなデータベース名）
- カウンターが上回った場合のアラート：80
- 応答：ジョブを実行（「チェックの再編成」）
ジョブを作成（「チェックの再編成」）
- ジョブでmsdb.dbo.sysjobactivityをチェックして、「再編成」ジョブが実行されているかどうかを確認します。そしてそれが...
- ジョブを停止し、停止するまでポーリングします。これには数秒かかる場合があります。
- （フルモードの場合）ログバックアップジョブをトリガーし、完了したら確認します。
- ログの空き領域カウンターがしきい値を下回ったことをsys.dm_os_performance_countersで再確認します。
- 「再編成」ジョブを開始します。
開発サンドボックスを含め、どこかでこれをテストして、本番サーバーに貼り付ける前に正しく機能することを確認してください。
表示されるのは、「再編成」ジョブが開始し、ログがいっぱいになることです。ログが1％になると、他のジョブを実行するWMIアラート（約30秒以内）がトリガーされ、「再編成」ジョブが実行されており、障害が発生している可能性があります。次に、「再編成」を停止し、バックアップを実行し、ログの空き領域が適切な値に戻ったことを確認してから、「再編成」ジョブを再開し、中断したところから再開します。
したがって、このシナリオでログを適切なサイズに事前にサイズ設定する理由は、増加/トリガー/ジョブ/停止/再起動の数を減らすことです。これにより、ログの効率が上がり、十分なスペースを確保できます。間に合わない時折の成長。
これは一種の奇妙なシナリオです。私はこれを数年前に踏みにじっていたと確信しています。明らかに、ここには根本的な根本的な問題があります。しかし、何百ものサーバーを扱う場合、このようないくつかのEdgeのケースが発生し、MacGyveringが仕事を終わらせる一時的なソリューションを除いて、いかなるビジネス上の理由でも、決して対処することができません。
安全で、論理的で、テストされ、十分に文書化されている限り、問題はありません。
これは私が通常行っていることです（私はまた、それぞれ80 + GBの大きなテーブルをいくつか持っています）（これは、以前の再編成作業を失うことなくいつでもインデックス再編成を停止できるためです）。
- インデックスの再編成中に、tlogバックアップを通常の30分の頻度から10分の頻度ごとに増やします
- 1分ごとにtlogの空き領域チェックを実行する別のセッションがあり、tlogの空き領域がしきい値を下回っている場合は、インデックス再編成セッションを停止して、tlogバックアップを開始（または待機）します。次に、インデックスの再編成を再開します。
私のインデックスメンテナンスフレームワークでは、インデックスを2つのグループに分類しています。1つはインデックスの再構築用で、もう1つはインデックスの再編成用です。インデックスの再構築では、インデックスの再構築セッションを停止したくないため、多少異なるアプローチを使用します（これにより、ロールバックが発生し、以前の作業がすべて失われます）。インデックスの再構築中に、監視セッションでtlogファイルの空き領域が使い果たされたシナリオに気付いた場合、監視セッションは自動的にtlogファイルを事前に増やし、最悪のシナリオ（つまり、ディスクがいっぱい）では、監視セッションが別のログファイル（しかし、後でそれをドロップします）別のドライブ（バックアップドライブ）
質問の著者と同じ問題があり、彼のコメントを見ると、私は同じ設定であったと言えます。私がREORGANIZEを実行しようとしたときに、ログはサイズに関係なく、テーブル全体のサイズの数倍にまで大きくなりました。
問題の原因はトランザクションレプリケーションでした。どうやら、ログはREORGANIZE操作が完了するまでバックアップできません。マイクロソフトの既知の問題だとどこかで読んだのですが、どこにあるのかわかりません。
トランザクションレプリケーションを無効にすると、ログバックアップは再び正常に機能し、再編成中に30秒ごとにログバックアップを実行するとうまくいきました。
私はあなたが次のように何かを実行していると仮定しています：
再編成時にインデックスを変更
残念ながら、部分的な整理を実行する方法はありません（たとえば、ログファイルを部分的に縮小する方法）。この問題を回避する方法は次のとおりです。
1）再編成を実行している間、データベースを単純復旧モードに設定しますが、それは受け入れられません
2）インデックスをパーティション分割する-インデックスをパーティション分割してほぼ同じサイズのパーティションを取得する方法を考えれば、各パーティションを個別に再編成（またはオンラインオプションで再構築）できるため、ログファイルの増加を制限できます。
これを行っていることは間違いありませんが、そうでない場合は、インデックスの最適化を行う前後にログファイルのバックアップを開始することをお勧めします。これにより、使用済みスペースを再利用できます。