0

ファイルがデータベースに完全にロードされているかどうかを知りたいです。

ここで戻りコードを確認すると、1 と 3 が失敗であることがわかります。

EX_SUCC 0
EX_FAIL 1
EX_WARN 2
EX_FTL  3

EX_WARN (戻りコード 2) には、次のケースが含まれます。

All or some rows rejected EX_WARN

All or some rows discarded EX_WARN

Discontinued load EX_WARN

これで、1 番目と 2 番目は管理可能になりました。

3 つ目は、ドキュメントを検索する必要がありました。これを読むと、「中断されたロード」には「致命的なエラー」、「CTRL-C」、および「スペース エラー」が含まれていることがわかります。この場合、おそらくレコードがないか、一部のレコードが拒否され、EX_WARN リターン コードが返され、ファイルがデータベースに不完全にロードされます。

拒否されたレコードがない場合は単純です。それは中断されたロードでした。エラーで終了する必要があります。しかし、一部のレコードが拒否された場合、ファイルがデータベースに完全にロードされているかどうかわかりません。(一部の行は拒否されましたが、私には受け入れられます。) 私は正しいですか?

はいの場合、解決策は何ですか？テーブル全体が DB にロードされたかどうかを知るにはどうすればよいですか?

4

2 に答える 2

2

SQLローダーがデータファイルからいくつかの行を挿入（およびコミット）したが、そのファイルの最後に到達できなかった（つまり、障害点の後に、他の方法では成功したはずのレコードがさらにあった可能性がある）状況が発生する可能性があります。

を使用して、SQLローダーではなく外部テーブルを選択しますINSERT INTO dest_table ... SELECT * FROM external_table。これは不可分操作であり、ロールバックの取り消しが不十分な場合（中間コミットを使用していないため）、失敗する可能性が（通常はわずかですが）あります。

また、データベースにロードされるまですべてを汎用テキストとして扱うことにより、外部テーブル/SQLローダーレイヤーでの拒否の可能性を最小限に抑えます。次に、構造を適用し、DMLエラーロギングを使用して不規則なものを処理します。これにより、拒否されたデータとデータベース内の拒否の理由に明確にアクセスできます。

于 2011-08-25T04:50:25.553 に答える
0

私は正しかったようです。私は Alex Poole のコメント、Gary の解決策 (Tom kyte も推奨) を良い解決策とみなし、同僚との教育で別のトリックを見つけました。

OPTIONS(ROWS=100000000) を入力する - 入力データが持つことができる以上のもの - を従来通りにロードします。(コミットが 1 つだけか、まったくないか) これで、 が何かをロードすると、すべてがロードされることがわかります。

于 2011-08-25T15:40:51.503 に答える