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
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@xxxxxxx 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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
