SQL*Loader job exits unexpectedly and causes table to be locked with NOWAIT

Question

I have a weekly report job that I run where I have to load about 48 logs with about 750k rows of data in each log. To facilitate this, we have been using a Java job that runs SQL*Loader as an external Process (using ProcessBuilder), one after the other. Recently however, this process has been terminating abnormally during the load which is causing a lock on the table and basically causes the process to grind to a halt until we can open a ticket with the DB team to kill the session that is hung. Is there maybe a better way to handle this upload process than using SQL*Loader or is there some change I could make in either the control file or command line to stop it from dying a horrible death?
At the start of the process, I truncate the table that I'm loading to and then run this command line with the following control file:
COMMAND LINE:
C:\Oracle\ora92\BIN\SQLLDR.EXE userid=ID/PASS@DB_ID load=10000000 rows=100000 DIRECT=TRUE SKIP_INDEX_MAINTENANCE=TRUE control=ControlFile.ctl data=logfile.log
CONTROL FILE:
UNRECOVERABLE
Load DATA
INFILE *
Append
PRESERVE BLANKS
INTO TABLE MY_REPORT_TABLE
FIELDS TERMINATED BY ","
     filler_field1          FILLER char(16),
     filler_field2          FILLER char(16),
     time               TIMESTAMP 'MMDDYYYY-HH24MISSFF3' ENCLOSED BY '"',
     partne          ENCLOSED BY '"',
     trans               ENCLOSED BY '"',
     vendor          ENCLOSED BY '"' "SUBSTR(:vendor, 1, 1)",
     filler_field4          FILLER ENCLOSED BY '"',
     cache_hit_count,
     cache_get_count,
     wiz_trans_count,
     wiz_req_size,
     wiz_res_size,
     wiz_trans_time,
     dc_trans_time,
     hostname          ENCLOSED BY '"',
     trans_list          CHAR(2048) ENCLOSED BY '"' "SUBSTR(:trans_list, 1, 256)",
     timeouts,
     success ENCLOSED BY '"'
Once all of the logs have finished loading, I rebuild the indexes on the table and then start the report process. It seems like it's just dying on random logs now, re-running the process it will fail at a different point each time.
EDIT: The reasons for the UNRECOVERABLE and SKIP_INDEX_MAINTENANCE are to speed the load up. As it is, it still can take 7-12 minutes for each log to load, it's even worse without those on. Overall it's taking about 18 hours for this process to run from start to finish.
Edited by: user6676140 on Jul 7, 2011 11:37 AM

Answer 1

Please note that my post stated:  "I have opened a ticket with Oracle support. after 6 days have not had the help that I need."
I also agree that applying the latest PSU is a Best Practice, which Oracle defines as "a cumulative collection of high impact, low risk, and proven fixes for a specific product or component".
With that statement I feel there should not be the drastic issues that we have seen.  Our policy is to always apply PSUs, no matter what the product or component, without issue. 
Except for now.  We did our research, and only open an Oracle ticket when we need expert help.  That has not been forthcoming from them, but we are still working the ticket.
Hence, I opened this forum because many times I have found help here, where others have faced the same issue and now have an insight.  When having a serious problem I like to use all of my resources, this forum being one of those.
To restate the question:
(1)     97% of our databases reside on RAC.  From the Search List for Databases, we do not see the columns Sessions:CPU, Sessions: I/O, Sessions: Other, Instance CPU%, and are told this is working as designed because you must monitor the instance, not the database, with RAC. 
     (a) After applying PSU2 the Oracle Load Map no longer showed any databases. 
All of this in (1) is making the tool less useful for monitoring at the database level, which we do most of the time.
(2) Within a few days of applying PSU2, we couldn't log into EM and got the error "Authentication failed. If problem persists, contact your system administrator."
    (b) searching through the emoms.trc files we found the errors listed above posting frantically. 
After rolling back PSU we are back in business.
However, there is still the need to remain current with the components of EM.
I am looking for suggestion, insights, experience.  While I appreciate Akanksha answering so quickly, a recommendation to open an SR is not what I need.
Sherrie