FileTableのインデックスを再構築することは良い習慣ですか？
データベースのバックアップとインデックスのメンテナンスの両方にOla Hallengrenスクリプトを使用しています。データベースにFileTableがあり、時々、そのPKインデックスの再構築には3時間近くかかり、残りの時間は非常に高速です。質問：FileTableのインデックスを再作成することは良い習慣ですか？ほんの数秒かかるのか、数時間かかるのかは異常です。私はファイルテーブルのインデックスの再作成についていくつかの検索を行いましたが、本当に役立つものは何も見つかりませんでした。
（コメントを回答に変換）
FileTableはFilestreamテクノロジーを使用しています。 From Paul Randalのブログ -FILESTREAMを設定する前に、必要に応じてNTFSボリュームをデフラグし、定期的に良好なスキャンパフォーマンスを維持します。
再構築する代わりに、提案されているようにntfsボリュームをデフラグする必要があります。
また、読むことを強くお勧めします- FILESTREAM実装のベストプラクティス -Pedro Lopes（シニアPM））
インデックスの再構築にかかる時間は、地域の要因に大きく依存します
ブロッキング
オンラインとオフラインの両方でインデックスの再構築にはロックが必要ですが、オフラインではさらに多くのロックが必要です。メンテナンス中にユーザークエリがテーブルにヒットする場合は、これが問題である可能性があります。一般に、これを直接監視せずにこれが問題であるかどうかを判断する良い方法はありません。
サーバー負荷
サーバー上で他のことが起こっている場合、他のデータベースでも、ハードウェアに負担がかかる可能性があります。バックアップ、CHECKDB、ETLロードなどにより、サーバーのリソースが不足する場合があります。
環境負荷
これの良い例は、VM（または物理サーバー）がすべてSAN上にある場合です。私はあなたのSAN=遅い（それはかもしれません！）とは呼びません）が、サーバーからSAN=環境に複数のSQL Serverが存在する場合、DBAはすべてのメンテナンスタスクを同時に実行するようにスケジュールする傾向があります。オーバーラップの内容によっては、スループットが大幅に低下する可能性があります。エラーログで15秒のI/O警告を確認できます。