過去数日間、私はOracleのSQL * Loaderを試して、データをOracleに一括ロードしようとしました。オプションのさまざまな組み合わせを試した後、従来のパスロードが直接パスロードよりもはるかに高速に実行されることに驚きました。
問題に関するいくつかの事実：
- ロードするレコードの数は60Kです。
- ロード前のターゲットテーブルのレコード数は7億です。
- Oracleのバージョンは11gr2です。
- データファイルには、日付、文字（ASCII、変換は不要）、整数、浮動小数点数が含まれています。ブロブ/クロブはありません。
- テーブルはハッシュで分割されています。ハッシュ関数はPKと同じです。
- サーバーに16個のCPUがある場合、テーブルの並列は4に設定されます。
- インデックスはローカルに分割されています。（ALL_INDEXESからの）インデックスの並列は1です。
- ターゲットテーブルには、PKとインデックスが1つだけあります。インデックスを使用して構築されたPK制約。
- インデックスパーティションを確認すると、パーティション間のレコードの分散がかなり均一であることがわかりました。
- データファイルは区切られています。
- APPENDオプションが使用されます。
- SQLを介したロードされたデータの選択と削除は非常に高速で、ほぼ瞬時に応答します。
従来のパスでは、ロードは約6秒で完了します。
ダイレクトパスロードの場合、ロードには約20分かかります。最悪の実行は完了するのに1.5時間かかりますが、サーバーはまったくビジーではありませんでした。
skip_index_maintenanceが有効になっている場合、ダイレクトパスのロードは2〜3秒で完了します。
私はかなりの数のオプションを試しましたが、どれも目立った改善はありません...回復不能、ソートされたインデックス、マルチスレッド（マルチCPUサーバーでSQL * Loaderを実行しています）。それらのどれも状況を改善しません。
SQL *Loaderがダイレクトモードで実行されている間、私が見続けた待機イベントは次のとおりです。
- イベント：dbファイルの順次読み取り
- P1 / 2/3：file＃、block＃、blocks（dba_extentsからインデックスブロックであることを確認してください）
- 待機クラス：ユーザーI / O
ダイレクトパスロードで何がうまくいかなかったのか誰かが知っていますか？または、問題の根本原因を実際に掘り下げるためにさらに確認できることはありますか？前もって感謝します。