Multithread is a way Informatica can parallelism the load into the = target using many concurrent sessions. Since it's direct load, each session will try to allocate its own = extents to load into. I would check if they have a very high number of threads. But also since you said the job failed and the table was loaded with = some rows (200K), this indicates that they have low setting for the = commit interval otherwise the table will be empty. Commit interval should be very high 1 million or higher. Waleed -----Original Message----- From: Thomas Jeff [mailto:jeff.thomas@xxxxxxxxxxx] Sent: Thursday, April 22, 2004 12:23 PM To: oracle-l@xxxxxxxxxxxxx Subject: RE: Informatica Bulk Mode behavior Waleed, The tablespace is locally-managed, 128MB extents. I'll have to ask about the multithread, can you tell me the ramifications of it? Thanks. -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Khedr, Waleed Sent: Thursday, April 22, 2004 10:24 AM To: oracle-l@xxxxxxxxxxxxx Subject: RE: Informatica Bulk Mode behavior I use it. It's using direct load OCI. Never had your problem. What is the extent size (initial/next ) for the table? Are they using = =3D =3D3D multithread in the mapping? Waleed -----Original Message----- From: Thomas Jeff [mailto:jeff.thomas@xxxxxxxxxxx] Sent: Thursday, April 22, 2004 10:33 AM To: oracle-l@xxxxxxxxxxxxx Subject: Informatica Bulk Mode behavior List, Is anyone familiar with how Informatica's bulk mode works? =3D3D20 We have a situation where I created a 4GB tablespace for a new and simple=3D3D20 truncate/load operation from Informatica, around 7 million rows estimated=3D3D20 to take up 1.5GB. =3D3D20 =3D3D20 Using bulk = mode, =3D which appears to be a direct load (in the SQL cache, the=3D3D20 INSERT = statement has a hint that I've never seen before: SYS_DL_CURSOR which=3D3D20 I = =3D assume stands for Direct Load), they run out of space in the tablespace after=3D3D20 about 200K rows have been inserted. If I then manually rebuild the table, the 200K rows gets compressed back down=3D3D20 to one extent. So there's a lot of either empty or preallocated space. Thinking somehow=3D3D20 the high-water mark was the culprit, I manually truncated the table before=3D3D20 they reran their job. =3D3D20 Still the same problem. =3D3D20 If the job runs in 'normal' mode, which is row-by-row processing, it runs fine,=3D3D20 although of course, performance is quite poor. Any ideas/experience as to how this bulk mode operates? Thanks. -------------------------------------------- Jeffery D Thomas DBA Thomson Information Services Thomson, Inc. Email: jeff.thomas@xxxxxxxxxxx Indy DBA Master Documentation available at: http://gkmqp.tce.com/tis_dba -------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------