We have a job that appends records to a table using SQL Loader (DIRECT=TRUE). The table has two unique indexes (no constraints). Last Sunday, the job loaded 11839 records into the table successfully, but the one of the unique indexes became unusable for unknown reason. I dropped the unusable index and recreated it. The index became valid. Then the developer reran the job and loaded the same 11839 records into the table (at that time we did not know the first run already loaded the records). Of course, two unique indexes became unusable again. I could not recreate the unique indexes due to the duplicate keys found. Finally, I deleted all of 23678 newly loaded records, recreated the unique indexes, and reloaded the 11839 records. Every thing is fine now. Here are my questions:
1. Why the same data crashed the index at the first time, but not at the end
2. After I recreated the unique index at the first time, those records were already in the table. Why did not the unique index complain for the duplicates when we reloaded the same 11839 records into the table?
Dave
_________________________________________________________________
Send and receive larger attachments with Hotmail Extra Storage. http://join.msn.com/?PAGE=features/es
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Boyd INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
