HEAPを再構築するとダウンタイムが発生しますか？

これは少し恥ずかしい質問です。長年これを見逃していたとは思えません。

401ヒープテーブルを持つベンダーサードパーティデータベースがあります。私は最近、Brent Ozarのスクリプトとセットアップsp_BlitzFirstを使用して15分ごとに実行し、待機統計などを収集しました。

明らかになったのは、24時間にわたって実行されるたびにForwarded Recordsを修正するように指示することでした。DMV全体でクエリを実行し、150,000を超える転送されたレコード値を持ついくつかのテーブルを取得した読者に、おそらく何がショックになるでしょう。

これを修正することは、テーブル全体にクラスター化インデックスを作成すること、または実行するための一時的な回避策として理解していますALTER TABLE [tablename] REBUILD。

しかし、私が見つけられなかったのは、これがテーブルをオフラインにするかどうか、およびこのコマンドを実行する前に知っておくべき他の問題があるかどうかです。

2008 R2のEnterprise Editionを使用していますが、この方法で実行すると停止の必要がなくなるのでしょうか。

ALTER TABLE [tablename] REBUILD WITH (ONLINE = ON);  

誰かこれについて何か経験がありますか？

朗報：15万回転送されたレコードは実際にはそれほど問題ではありません。転送されたレコードは、サーバーが稼働している限り追跡されます（特定の2012/2014ビルドのバグに関するいくつかの落とし穴があります）。

オンラインで機能している場合でも、IOスループット、テーブルのサイズ、非クラスター化インデックスの数、およびワークロードに応じて、ユーザーはそれに気付きます。

これが私がそれに取り組む方法です：

• 転送されたレコードの警告を含むテーブルを、最小のテーブルサイズから最大のテーブルサイズ（転送されたレコードの数ではない）まで一覧表示します。
• これらのテーブルを順番に、一度にいくつかずつ再構築します。これを自動化しないでください-小さなテーブルの再構築にシステムがどのように応答するかを感じたいと思います。あなたのサーバーが追いつくことができれば、あなたはかなり早く学ぶでしょう。
• トランザクションログの使用状況に注意してください。ログファイルが10 GBで、50 GBのヒープを再構築しようとしている場合、問題が発生する可能性があります。これらの問題を軽減するには、メンテナンスウィンドウの間にログを事前に拡大し、その間、頻繁にログバックアップを実行します。こんなに多くの作業をする必要はありません。
• 今後、ベンダーと協力して、これらのテーブルにクラスター化されたキーを配置します。はい、ヒープが適切な場合がありますが、転送されたレコードの問題が発生している場合は、おそらくヒープに適した状況ではありません。