オンラインとオフラインのインデックスの再構築
私はいつも眉をひそめていると思う意見を探しているので、事前に謝罪します。
現在、すべてのインスタンスがSQL Server Enterprise Editionである環境にいます。メンテナンスタスクはカスタムプランによって実行されています。このプランは、デフォルトで夜間にオフラインで再構築します。
夜間のメンテナンスウィンドウはありません。また、環境は多国籍であるので、メンテナンスの「夜間」の部分は、必ずしも最低のアクティビティポイントを意味するわけではありません（ただし、ケースの95％でそうです）。また、積極的なインデックス作成のメンテナンスが原因で、現在実行速度が遅い夜間ジョブがたくさんあります。 （顧客データを含む300GBのテーブルのインデックスの再構築を待機してスタックしたレポートクエリは、私をこのルートに導きました）
以下は主に良い影響があると思いますか？
- 再編成のために10％の最小フラグメント値を追加します（現在、％に関係なく毎晩行われます）
- 最小再構築要件を30％に変更（現在は5％）
- デフォルトの動作をオンラインに変更する
- 最小ページ数を1000に変更する（現在は50）
主に私がここで尋ねているのは、現在のメンテナンススケジュールがあまりにも積極的であると想定して正しいのでしょうか。また、上記の4つの変更は正味のプラスの効果をもたらします。
私はほとんど毎晩すべてのものをすべて再編成することを心配しています...それは過度に思えます。
それが正味のプラスになるかどうかを知るのは難しい。これらは非常に簡単です：
- すべての操作をONLINEに設定します。
- 1000ページ未満のテーブルを無視する
ただし、それらをテストする必要があります。
しかし、デフラグ/再構築が読み取りワークロードにどのような影響を与えるのか、また、ある％まで延期するのが良いか、何も得られないか、またはいくつかの読み取りクエリがさらに悪化するかどうかはわかりません。
他の人々はすでにこのタイプのメンテナンスを完成させて、推測ゲームからあなたを連れ出しました。 Ola Hallengrenのスクリプト または私たちのツール Fragmentation Manager を取得します。パラメータ値を変更するだけで、提案したとおりに変更できます。そして、これらの人々はあなたがまだ遭遇していない多くのバグをすでに解決していて、まだ考えていないことを考えていることを忘れないでください。また、新しい操作が新しいバージョンでオンラインで提供されるか、新しいオプションがさまざまなメンテナンス機能に追加されると、これらのツールとスクリプトが更新されます。あなたがやったことは、愛情を込めてホイールを再発明することとして知られています：
過去の投資のために、より自動化されたソリューションへの移行を拒否することは、昨年支払ったので恐ろしい家政婦や庭師を維持するようなものです。時には、コードを切る必要があるだけです。
私はデータベースが非常にトランザクション的であり、再構築が必要だと思います。そして国際的であり、いつでもアクセスできます...したがって、私の意見では、現状のまますべてを残し、オンライン再構築に変更します。
すべてが常に-無駄です。しかし、列車のスマッシュではありません。タスクで断片化のチェックを緩和します-わずかに積極的に設定しません-10％断片化してから再編成します。 20％再構築します。
したがって、2つの変更のみを導入し、評価して再度調整します。このようにして、常にすべてではなくオプションを考慮に入れます。 ONLINEなので、アクセスできる人がいます。
提案されているように、Ola Hallengrenの作品を確認してください。コーディングの見事な例...インスピレーションを与える。
幸運を！
主な違いは次のとおりです。
OFFLINEインデックスの再構築は、ONLINEの再構築よりも高速です。
SQL Serverのオンラインインデックスの再構築中に必要な追加のディスク領域。
SQL Serverオンラインインデックスの再構築で取得されたSQL Serverロック。
このスキーマ変更ロックは、テーブルへの他のすべての同時アクセスをブロックしますが、古いインデックスが削除され、統計が更新されている間、非常に短い期間だけ保持されます。