当社の製品は、約 350 人の候補者を同時にテストします。テストの最後に、各候補者の結果は、インデックスでいっぱいのデータ ウェアハウスに移動されます。テストごとに、約 400 のレコードがデータ ウェアハウスに入力されます。したがって、400 x 350 は多くのレコードです。データ ウェアハウスにあまりレコードがなければ、すべてうまくいきます。しかし、データウェアハウスにすでに多くのレコードがある場合、多くの挿入が失敗します...
一日の終わりにのみ再構築されるインデックスを持つ方法はありますか、それとも本当の問題ではありませんか? または、これをどのように解決しますか？
データ ウェアハウスでは、読み込み前にインデックスと制約を削除し、後で再作成するのが一般的です。制約 (FK) を取り除く場合は、読み込みプロセスがこれを処理することを確認してください。チェック制約も削除し、チェック検証を ETL ソフトウェアに移動します。
140K は多くの行ではありません。テーブルのデザインと、挿入が失敗したときに発生するエラーを投稿してください
次のことをお勧めします。インデックスがレポート用に調整されている別のテーブル（履歴と呼びます）に今日のものを除いて、すべてのデータを保持します。今日のデータを別のテーブルに保持し（今日と呼びましょう）、深夜にジョブを実行して、データを今日のテーブルから履歴テーブルに移動します。Todayテーブルでは、挿入のパフォーマンスを向上させるために、最小限のインデックスを作成する必要があります。この設計を実装することにより、レポートが挿入で混雑していないことを確認できます。さらに、目的に合わせて調整された2つのテーブルがあります。一般に、高速挿入と高速選択の両方でテーブルを調整することは困難です。
私は、正規化されたデータ ウェアハウスと Kimball スター データ ウェアハウスの両方を使用してきましたが、これはあなたが直面する問題ではないように思えます。小規模なデータ ウェアハウスであっても、140000 行は多くの行ではありません。
挿入が失敗するのはなぜですか? 通常、Kimball スタイルのウェアハウスでは、挿入が失敗することはありません。たとえば、ファクト テーブルでは、挿入には常に、ディメンションと粒度 (日付または時刻のスナップショットなど) に関連する一意の主キー セットがあります。ディメンション テーブルでは、変更が検出され、新しいディメンションが挿入され、既存のディメンションが再利用されます。正規化されたウェアハウスでは、通常、物事を一意に保つ何らかの改訂メカニズム、アーカイブ プロセス、または発効日があります。
DW の哲学やアーキテクチャに関係なく、これらの行を一意に保つものがあるはずです。
（コメントで述べたように）すべての列を含む単一のインデックスがある場合、それはおそらく（どのデータベース設計においても）あまり有用なインデックスではありません。インデックスがクエリに使用されていることは確かですか? また、一意であるとマークされており、その制約に違反していますか? いずれにせよ、それはかなり大きな複数列のインデックスであり、比較すると比較的コストがかかります-これによりタイムアウトが発生する可能性があります-接続でいつでも修正して永遠に待つことができますが、私はから問題を攻撃しますデザインの視点。