私は、Azure SQLデータウェアハウスへのリフト・アンド・シフトを評価しているアプリケーションで使用される一連のキャッシュのようなテーブルを持っている。テーブルを切り捨てるが、Azure SQLデータウェアハウスの統計情報を残す
アプリケーションは、ロードされ、ファクトテーブル(時間、場所、製品などの2次元または3次元)の結合に使用される一連のキャッシュのようなテーブルを使用します。キャッシュに似たテーブルはアプリケーションを介して共有され、異なるレポートは、ある列の識別子として任意の文字列で行をロードし、ファクト表の次元列の外部キーをロードします。
テーブルがTRUNCATEされたときに統計情報が失われるようです。ヒントなどを介して統計を保持することは可能ですか?
どのようなユースケースですか?あなたがテーブルをTRUCATEするとき、残っているのはスキーマだけです。統計はないため、データはありません。テーブルが再水和されると、読み込まれたものに基づいて新しい統計が表示されます。古い統計情報を残しておくのが貴重だと考えるユースケースについて詳しく説明できますか? – SQLmojoe
UIのユーザー選択がデータベース上の操作に変換されるため、キャッシュのような表は1日を通して段階的にロードされます。したがって、ユーザーの日前に統計情報を収集した場合、一晩中テーブルがTRUNCATEされるため、代表者ではありません。すべてのレポートで統計情報を収集することは、おそらく過剰な(おそらくロック競合を招く)可能性があります。私はTRUNCATEを使うべきかどうか調べなければならない統計をどこで偽ることができるのかを読んだと思った。私はたぶんDELETEを使用して、ログを受け入れて統計情報を静的に保つことができます。 – Steve
統計情報を偽造する能力はありません。 QOは、合理的な時間内にできる最高の計画を策定するために統計情報(およびその他のもの)を使用します。偽の統計情報を提供することは、コストベースのQOを持つという目的を破るものです。誤って偽の統計を使ってまともな計画を取る確率は、統計がないまともな計画を得ることと同じです。また、統計の作成と更新ではロック競合が発生することはありません。それはブロックすることがありますが、ロックの競合と同じではありません。 – SQLmojoe