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