My indices are breaking things

Question

My indexes are getting corrupted somehow, and I need some
expert advice. I have several tables with identical
structure, which are created like this:
create or replace table &1(
     ssn          char(9) not null unique,
     name          varchar2(20) not null,
     address          varchar2(25),
     city          varchar2(15),
     state          char(2),
     zip_code     char(5),
     phone_number     varchar2(12)
tablespace &1;
I always try to have every table and related files under
the same name; for instance, a table named 'XYZ' will reside
on a tablespace called 'XYZ' (see &1 above), will have an
associated index 'XYZ, and the data used by sqlldr will be in
a file called 'xyz.dat' with a control file named 'xyz.ctl'
(see $CLIENT below).
The following bash script is used to truncate and reload my
tables periodically:
#!/bin/bash
if [ $# != 1 ]; then
     echo usage: load \<client-name\>
     exit 1
fi
CLIENT=$1
cd $HOME/oracle/
if [ ! -f $CLIENT.dat ]; then
     echo load\: unknown client \'$CLIENT\'
     exit 2
fi
sqlplus username/password @unindex $CLIENT
sqlplus username/password @truncate $CLIENT
sqlldr username/password errors=200000 \
     direct=true parallel=true control=$CLIENT
sqlplus username/password @newindex $CLIENT
exit 0
These are the issues:
When a table is created, the 'UNIQUE' constraint on the
primary key (SSN) forces an index to be created. This index
is making my life miserable. Is there any way to prevent
this index from being created (I will add it afterwards)?
Or is there at least a way to use a name of my choice for that
forced index?
The existence of that dawn index also prevents me from using
the more efficient 'direct' and 'parallel' SQL*Loader options.
One more time, this index (obviously needed for fast access
and SSN uniqueness) is in the way.
After fiddling around a little with the script above
(taking out te 'direct' and 'parallel'), my tables
seem to load properly, without any errors. However,
later on I get a message about the indexes being in a
bad or unusable state.
Thanks for any insight and comments.
-Ramon F. Herrera

Answer 1

I did some research on SQLLDR back in 12/2000, using both the direct & parallel options. At the time I wrote this, we were using Oracle 8.1.6, but the info should be true for 8.1.7, and may be true for 9i:
Oracle's SQL Loader has two major modes of loading data, and one of these two modes has two major options. The first mode is conventional-path. This mode would most closely resemble DB2's IMPORT. Basically, under the covers, this is a SQL INSERT. It's the slowest method, but would probably be faster than a pure SQL INSERT. Indexes and constraint checking are fully maintained.
The second mode is direct path, which can be run with or without a Parallel setting. Without the Parallel setting, indexes can be maintained, and PK/Unique/NULL constraints are enabled. This mode will check for foreign-key constraints, but if a foreign-key constraint is violated, the FK constraint is DISABLED! Meta information about the violations can be stored in an exception table. The rows themselves remain in the table, and are accessible by the user! We will need to be very careful if we try to implement this method. Oracle's fastest load mode (via SQL Loader), using Parallel setting, requires that data be added in APPEND mode. Generally, SQL Loader cannot handle the presence of indexes. An additional parameter option, SKIP_INDEX_MAINTENANCE=TRUE, can be added, but the index needs to be rebuilt after the load has completed. In my testing, the index rebuild worked fine when I did the SQL LOAD on an empty table. No timing info was given, but the ALTER INDEX...REBUILD ran in under five seconds. When I reran the load--using APPEND (with the same data), Oracle would not let me rebuild the index: (ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found). I was also unable to drop the index: (ORA-02429: cannot drop index used for enforcement of unique/primary key). The only work around I have discovered so far is to drop the foreign key constraints, drop the PK constraint, delete from the table, re-add the PK constraint, then re-add the foreign key constraints. If the Fact tables are empty, the run time isnt too long, but you could spend a lot of time gathering the information to build your drop/delete/add script(s). If the Fact tables are already populated, the run time could also be extravagant. Basically, this means that while direct/parallel load is fine for the initial load, it has to be used with great caution on subsequent loads.