他のユーザーのアプリのHEAPテーブルにクラスター化インデックスを追加する

Question

SQL Server 2005ベースの独自のアプリケーションを使用しています。これには、多くのHEAPベースのテーブルがあります（つまり、クラスター化インデックスがありません）。長年にわたり、これらのテーブルは大きく断片化（たとえば、99％の断片化）しました。それらを最適化する必要があります。

現在、SQL Server 2005では、これを直接行う方法はありません。私は次のいずれかを行えます：

既存のフィールドにクラスター化インデックスを作成し、それを保持する
そのインデックスを作成し、テーブルを再構築してから削除します
自分のフィールドを追加します（例：自動インクリメントキー）

さて、これはベンダーによって書かれた大きなアプリです-巨大なブラックボックス。私は彼らのものをいじくり回したくはありません。テーブルの使い方についてはよくわかりません。これを行う最も影響の少ない方法は何ですか？

そしてフォローアップとして、これらのHEAPベースのテーブルの多くがあり、アプリケーションによって使用される12を超えるデータベースがあります。選択肢＃2または＃3を自動化する方法はありますか？または、変更するテーブルをどのように選択すればよいですか？

UPDATE：
（非常に役立つ）回答からの質問に答えるには：

パフォーマンスは許容できません。これはテーブルが極端に断片化されているためであり、定期的に最適化するのはクライアントの責任であるとベンダーがクライアントに言った
アプリケーションには2つのインスタンスがあります。テスト用と本番用です。
まず、すべてのクラスター化テーブルを最適化しました。これにより、パフォーマンスが大幅に向上します
ベンダーのサポートチームは非常に役に立たなかった。彼らは、テーブルをデフラグするのは私たちの責任だと私たちに言いました。 HEAPベースのテーブルの最適化を推奨する方法を尋ねたところ、クラスター化インデックスを追加する必要がありますか？ -彼らは「それはマイクロソフトの質問です」と答えただけです。

つまり、カスタマーサポートチームは次のことを明らかにしました：テーブルをデフラグする必要があります。その方法はあなたのビジネスです。

将来のバージョンについて：はい、新しいバージョンが開発されており、最終的にSQL Server 2012に移行します。ただし、パフォーマンスソリューションが必要です今日。

最後に、デフラグには時間がかかりすぎます。それは問題ではありません。彼らは99％の断片化を持つ巨大なテーブルを持っています。アプリケーションは夜間使用されません。私はそれらをデフラグするときに一度に何時間も費やすことができます。

Eric Higgins · Accepted Answer

断片化されたヒープは重要です。ヒープが大きいほど、データのウォークが難しくなります。パフォーマンスが低下します。

CIを作成してドロップすると、ご存じのとおりテーブルの行が並べ替えられます。ベンダーがソリューションを提供しておらず、断片化に対処するのはあなたの責任である場合、それはまさに私が過去に行ったことです。それが私だったら、CIを離れることはありません。列を追加しないでください。列を追加すると、テーブルの機能が永続的に変更されます。CIをそのままにしておくと、同じ議論が生じる可能性があります。

これを行う場合、CIを作成するための適切なストレージがあることを確認してください。これには、少なくともヒープのサイズと等しいストレージが必要になるため、サービスレベルの要件を検討してください。

Jon Seigel · Answer

修正が必要な問題を特定したと仮定して説明しますが、まだ完全には確信していません。

私の答え here と同様に、ベンダーアプリケーションに関しては2つのケースがあります。

アプリケーションは現在ライセンス下にあるか、ベンダーまたは所有者が干渉を望んでいません。

この場合、必ずnotスキーマを変更してください。。

スキーマを変更すると、実際にはライセンス契約が無効になる場合がありますが、将来のスキーマの更新で問題を修正する場合、ベンダーに問題が発生する可能性もあります。ベンダーの観点からの個人的な経験から言えば、スキーマ変更を正常に適用する能力に影響を与えるため、データベースでのオブジェクトの作成を停止するようクライアントに非常に積極的に指示する必要がある場合があります。（私は単に言っているだけではありません-数か月前に、クライアントが作成したオブジェクトからの予期しない依存関係のために、1つのクライアントでスキーマの更新が失敗したケースがありました。インデックスを追加するシナリオとは少し異なりますが、それでも、出てきます。）

データベースレベルの変更で問題が発生することはまれですが、計画していることについてベンダーが問題がないことを確実に確認する必要があります。

このシナリオの最良のオプションは...実際には、自分で変更を加えないことです。これらの変更を行うことが重要である理由を証明する説得力のある事例をまとめ、将来のリリースで実装するためにベンダーに提示します。

ベンダーの観点から見ると、提案は具体的で、実装とテストが簡単で、すべてのクライアントに高いプラスの影響を与えることが理想的です。大規模なアプリケーションでは、ヒープであるすべてのテーブルをクラスター化インデックスに変換することをお勧めします（おそらくそうであるでしょう）が、これは完全なスターターではありません。代わりに、ご使用の環境でこの種の変更を行うことでメリットが得られる、最も重要な5〜10の表または2〜3のアプリケーション領域を把握してください。
アプリケーションのライセンスが不足しているか、ベンダー/所有者がアプリケーションで何をするかを気にしていません。

この場合、任意のインデックスを追加できますが、オブジェクトは同じ名前のままにしておく必要があります（sameオブジェクトとは言っていません）。アプリケーションとデータベースが内部でどのように機能するかに応じて、ここには多くのオプションがあります。今後もベンダーが提供するスキーマの変更を適用する予定がある場合は、veryを注意深く読み、undoすべての変更のためのスクリプト。

変更を正常に行うための鍵は、アプリケーションの機能を維持することです。重要な変更を行う場合は、言うよりも言うまでもありません。

つまり、クラスター化インデックスを追加するだけでかなり安全です。課題は、各インデックスに適切なキーを選択することであり、これは自動ではなく手動で行う必要があります。この部分を適切に行う唯一の方法は、テーブルのアクセスパターンと目的を理解することです。

考えてみれば、他のケースと同じプロセスを実行できます。全体的な影響が最も大きい5〜10個のテーブルを特定し、それらを最初に修正します。それだけで十分です。

編集：この回答は、より一般的な意味で、 video 形式で利用できるようになりました。