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のヒープを再構築しようとしている場合、問題が発生する可能性があります。これらの問題を軽減するには、メンテナンスウィンドウの間にログを事前に拡大し、その間、頻繁にログバックアップを実行します。こんなに多くの作業をする必要はありません。
- 今後は、ベンダーと協力して、これらのテーブルにクラスター化されたキーを配置します。はい、ヒープが適切な場合がありますが、転送されたレコードの問題が発生している場合は、おそらくヒープに適した状況ではありません。