FW: 10g sqlldr and PARALLELism

  • From: Tim Gorman <tim@xxxxxxxxx>
  • To: "'Oracle-L (E-mail)" <oracle-l@xxxxxxxxxxxxx>
  • Date: Sat, 22 Jan 2005 19:58:31 -0700


Try setting SKIP_INDEX_MAINTENANCE from its default of FALSE to TRUE.  Each
parallel job might be attempting to maintain indexes simultaneously (which
would result in queueing to run sequentially).

Create a procedure/script to rebuild indexes once at the end, after all
loads have completed successfully.

Hope this helps...


on 1/19/05 4:09 PM, Tanel P=F5der at tanel.poder.003@xxxxxxx wrote:

> Hi,
> Given your server, I assume that your IO is fast enough for these paralle=
> loads as well?
> If you have logging on and lousy IO for redologs, then this might be a
> reason why parallel jobs get even slower. Although such drastic performan=
> drop probably isn't due logging bottleneck.
> So I guess the logical next step is to run your parallel sqlldr sessions
> again and check from v$session_event (and v$sesstat) where most of the ti=
> is going. If it doesn't ring a bell, then you could also run the normal
> sqlldr job and check whether there's a difference in proportions of time
> spent. Also you could use sql trace with waits for getting this informati=
> but I think in this particular case identifying the session id's and usin=
> v$session_event would be easier.
> Tanel.
>> I am running Oracle 10g on an IBM P690 with AIX.  For a particular job I
>> load 8GB using sqlldr, direct=3Dyes in two hours.  I wanted to speed this
>> up, so I broke the job up into four jobs, each loading 2GB each with the
>> parallel=3Dtrue option turned on.  These four jobs now take six hours
>> each.   Why is there a time increase?
>> I can't find a parameter that will solve the apparent contention that is
>> going on.
>> Any ideas where I may be going wrong?
>> Thanks ... Roger


Other related posts: