0

状況 ：

  • 私はテーブルAを持っています。

  • 大量のデータをテーブルAにロードしたい（たとえば、数百万レコード以上）

さて、オプションなどを探して、ロード時にテーブルのインデックスを無効にする必要があるという結論に達しました。

* alter index your_index unusable; *

しかし、ロード中に他のプロセスやシステムがテーブルAのデータを検索し、テーブルAにデータを挿入する可能性があります。したがって、次を使用する必要があります。

*システム設定の変更skip_unusable_indexes=true; *

データがロードされた後、インデックスを再構築し、フラグをクリアします。

ここに質問があります：

  1. クエリは私のインデックスを使用します（使用不可に設定されている場合）-大きなテーブルについて話しているのですが、インデックスがないとタイムアウトします

  2. 1が真の場合、インデックスを再構築する前に新しく挿入されたレコード（つまり、バルクロードではなく他のプロセスを介して挿入されたレコード）はどうなりますか？クエリされたときに返されますか？あるセッションでインデックスを部分的に再構築/無効にして、他のセッションで保持することは可能ですか？

つまり、大規模なシステムではそれほど珍しい状況ではないはずです。ロードするデータはたくさんありますが、システムは応答性を維持する必要があります。

要約すると、パーティショニングとパーティション交換は進むべき道のように見えます

4

2 に答える 2

2

インデックスが使用できない場合、クエリはそれを使用できません。クエリがインデックスを使用できない場合にタイムアウトになり、データの読み込みと同時にクエリを実行する必要がある場合、インデックスを使用不可としてマークすることはできません。ロード中にインデックスのメンテナンスのオーバーヘッドが発生する必要があります。

状況によっては、大量のロードをステージング テーブルに実行し、インデックスをステージング テーブルに構築し、パーティション交換を行って新しいテーブルを交換できるように、テーブルをパーティション分割することでメリットが得られる場合があります。 、移入したステージング表の表の空のパーティション。もちろん、データについて詳しく知らなければ、この方法でテーブルをパーティション分割することが可能かどうか、またはクエリのパフォーマンスに他の悪影響があるかどうかを知ることは不可能です。

于 2012-08-06T16:50:26.970 に答える
0

データがファイル形式から来ている場合、SQL*Loader の使用が解決策であるかどうか疑問に思っています。インデックス/制約の無効化、コミット頻度など。

高性能データ読み込みツールです。ニーズに合う場合と合わない場合がありますが、別のオプションが提供されます。

あなたの状況は、システムが非アクティブであるか、オンラインのユーザー数が少ないときに、私が処理した大量のデータ ロードが行われたという点で、私が以前に遭遇したものではありません。

于 2012-08-06T19:42:10.187 に答える