Why are my foreign keys disabled after running sqlldr?

Question

During our build process, we run sqlldr to populate our database with some sample data. On every table that sqlldr touches, the foreign keys are disabled after sqlldr runs.

According to this Ask Tom posting:

sqlldr will only disable constraints that relate to other tables (eg: foreign keys) NOT the primary key.

SQLLDR will only re-enable the constraints which IT disabled, not the ones you did yourself.

I would take that to mean that my foreign keys should be enabled.

All of our sqlldr control files are similar to this one:

options (direct=true, rows=20000)
load data
infile "clinical_code.txt"
append
into table clinical_code
fields terminated by "|"
trailing nullcols

The rows count is intentionally larger than the number of rows in the data file because if it was smaller, it corrupted my primary key.

Why is sqlldr not re-enabling my foreign keys like the documentation seems to imply?

I am fine writing the SQL to re-enable the indices if necessary. I'd like to know why this is happening.

Using conventional load path is an ok alternative, but it would add 2 minutes to our build process and I'd like to avoid that if possible.

Answer 1

Hi Josh,

From the SQL*Loader 10gR2 documentation :

Integrity constraints that depend on other rows or tables, such as referential constraints, are disabled before the direct path load and must be reenabled afterwards. If REENABLE is specified, SQL*Loader can reenable them automatically at the end of the load. When the constraints are reenabled, the entire table is checked. Any rows that fail this check are reported in the specified error log. See Direct Loads, Integrity Constraints, and Triggers.

It seems you have to specify the REENABLE keyword to enable the constraints automatically after the load.