sqlldr codes retour - ex_warn

Question

Je veux savoir si mon fichier est chargé complet dans la base de données. Si vous vérifiez les codes de retour here vous pouvez voir que 1 et 3 est un échec.

EX_SUCC 0 
EX_FAIL 1 
EX_WARN 2 
EX_FTL 3 

EX_WARN (code de retour 2) comprend ce cas:

All or some rows rejected EX_WARN 

All or some rows discarded EX_WARN 

Discontinued load EX_WARN 

Maintenant, le premier et le second est gérable.

Pour la troisième j'ai dû chercher dans les docs. Si vous lisez this, vous pouvez voir que les «charges abandonnées» incluent «erreurs fatales», «CTRL-C» et «erreurs d'espace». Dans ce cas, je n'aurais probablement aucun enregistrement ou certains enregistrements rejetés, le code de retour EX_WARN et le fichier incomplet chargé dans la base de données.

S'il n'y a pas d'enregistrements rejetés est simple: il s'agissait d'une charge abandonnée. Je dois sortir avec erreur. Mais quand j'ai un enregistrement rejeté, je ne suis pas sûr que mon fichier est complètement chargé dans la base de données. (Certaines lignes rejetées sont acceptables pour moi.) Ai-je raison?

Si oui, quelle est la solution? Comment savoir si la table entière a été chargée dans DB?

Answer 1

SQL Loader a inséré (et validé) certaines lignes dans un fichier de données mais n'a pas pu atteindre la fin de ce fichier (il pouvait y avoir plus d'enregistrements après le point de défaillance qui aurait autrement réussi).

J'opterais pour une table externe sur SQL Loader, en utilisant un INSERT INTO dest_table ... SELECT * FROM external_table. Ce serait une opération atomique et il y a une chance (généralement faible) qu'elle échoue si vous avez un nombre insuffisant d'annulations pour la restauration (puisque vous n'utilisez pas de commits intermédiaires).

Je réduirais également les possibilités de rejets dans la couche table externe/SQL Loader en traitant tout comme du texte générique jusqu'à ce qu'il soit chargé dans la base de données. Ensuite, j'applique la structure et utilise la journalisation des erreurs DML pour gérer tout ce qui est irrégulier. De cette façon, vous avez un accès clair aux données rejetées et la raison du rejet dans la base de données.

Answer 2

On dirait que j'avais raison. je compte en bonne solution le commentaire d'Alex Poole, la solution de Gary (recomended aussi par Tom Kyte), et je trouve un autre truc dans le ecuation avec mes coleagues:

Pour mettre OPTIONS (rows = 100000000) - plus les données d'entrée peuvent avoir - et charger conventionnellement. (Nous aurons un seul commit ou aucun) Avec ceci, nous savons que, si quelque chose est chargé, tout est chargé.