プロジェクトでMS SQL Server 2014 Standard Editionを使用していますが、最近、ユーザーによるシステムの通常の使用中にインデックスの断片化が高くなるという問題が発生しました。
現在、インデックスはメンテナンス期間中に1日に1回再構築されますが、特定の操作の後、一部のインデックスが非常に高くなることがあります(30%を超える)。その他の問題は、処理するデータが大量にある場合、断片化が単一のプロセス中に発生するため、プロセスはかなり早く開始されますが、断片化が始まるとすぐにパフォーマンスが大幅に低下します。
このような状況で何ができますか?追加のメンテナンスウィンドウを取得することは、かなり不可能です。定期的に一部のインデックスのみを再構築することを考えていましたが、データベースでロックやデッドロックが発生する可能性があります。
可能であれば適切に確認します。たとえば、先読みの効果が低下したときに読み取りパフォーマンスが大幅に低下したり、システムがページ分割の数に追いつくのに苦労している場合は、最も重要なインデックスのFILL FACTORを穏やかに調整することを検討するかもしれません。これにより、読み取りのコストと(Standard Editionで利用できる限られたバッファープールで)キャッシュできるページ数を犠牲にして、書き込みパフォーマンスが向上します。
まず、FILL FACTORが低いことに夢中にならないでください。最も問題の多いインデックスの管理可能な数を選び、メンテナンスウィンドウ間の通常のワークロード中に過度の分割を回避するために必要な空き容量を見積もり、低いフィルファクター(通常は約90以上)の設定の影響をテストします。最初のテストの%)。 しないでください盲目的にすべてのインデックスに対して低いFILLFACTORを設定します。
このシステムには、10回のうち9回、次善に設定されたFILL FACTORに直接起因する問題よりも大きな問題があります。システムの重要なパフォーマンスの側面を監視し、実際の履歴データの適切な技術分析に基づいて、変更を正当化できる必要があります。
読み物:
いくつかのオプション:
あなたは断片化がパフォーマンスの問題を引き起こしていると述べました。多くの場合、断片化のように見えるようですが問題ですが、実際には問題は統計が不良です(テーブルで変更されたデータの量が原因です)。 。
関連するテーブルの統計情報を更新するだけの方がよい場合があります。
インデックスを再構築すると統計が更新され、断片化が問題であるという認識が強まります。これらの操作は通常、インデックスの再構築よりもはるかに混乱が少なく、リソースを集中的に使用します。
_UPDATE STATISTICS dbo.YourTableName WITH FULLSCAN;
_
テーブル全体をスキャンしないように「サンプルパーセント」をいじることもできます。
_UPDATE STATISTICS dbo.YourTableName WITH SAMPLE 50 PERCENT;
_
サンプリングされた統計がFULLSCAN
より長くかかる場合がある転換点があるため、さまざまなサンプルレートをテストするときは注意してください。これは、複数の要因(データや使用可能なリソースなど)によって異なります。 Erin Stellatoはこの件について素晴らしい記事を投稿しています: サンプルサイズと更新統計の期間:それは重要ですか?
スキーマ/ワークロードを変更して、断片化の一般的な原因を回避し、問題が始まる前に速度を低下または停止できる場合があります。主な例は、uniqueidentifier
主キーがNEWID()
によって入力されるのを避けることです。
より一般的には、適切なクラスター化インデックスは、狭く、一意で、静的で、常に増加する必要があります。
通常のユーザーアクティビティ中にインデックスを再構築することが非常に重要な場合は、SQL ServerのEnterprise Editionへのアップグレードを正当化する必要がある場合があります。次に、発生するインデックスの再構築を指定できます "ONLINE" :
_ALTER INDEX [IX_YourIndex] REBUILD WITH (ONLINE = ON);
_
これにより、インデックス操作中に、ユーザーアクティビティが最後(短時間)以外で続行できるようになります。もちろん、再構築は引き続きサーバーリソースを使用するため、全体的なパフォーマンスに影響を与える可能性があります。
値札が大きいので最後に入れました。この方向に進む前に必ず他のオプションを検討し、REBUILD
sが実際に問題を解決するかどうかをテストする必要があります。