FW: 10g sqlldr and PARALLELism

From: Tim Gorman <tim_at_evdbt.com>
Date: Sat, 22 Jan 2005 19:58:31 -0700
Message-ID: <BE1860E7.2244D%tim@evdbt.com>

Roger,

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...

-Tim

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

> Hi,

>=20
> Given your server, I assume that your IO is fast enough for these paralle=
l
> loads as well?

>=20

> 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=
ce
> drop probably isn't due logging bottleneck.

>=20

> 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=
me
> 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=
on,
> but I think in this particular case identifying the session id's and usin=
g
> v$session_event would be easier.

>=20

> Tanel.

>=20
>> 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?
>>=20
>> I can't find a parameter that will solve the apparent contention that is
>> going on.
>>=20
>> Any ideas where I may be going wrong?
>>=20
>> Thanks ... Roger

--
http://www.freelists.org/webpage/oracle-l

Received on Sat Jan 22 2005 - 22:00:11 CST