We have a situation where I created a 4GB tablespace for a new and
simple=3D20 truncate/load operation from Informatica, around 7 million
rows estimated=3D20 to take up 1.5GB. =3D20 =3D20 Using bulk mode, =
which
appears to be a direct load (in the SQL cache, the=3D20 INSERT statement
has a hint that I've never seen before: SYS_DL_CURSOR which=3D20 I =
assume
stands for Direct Load), they run out of space in the tablespace
after=3D20 about 200K rows have been inserted.

If I then manually rebuild the table, the 200K rows gets compressed back
down=3D20 to one extent.

So there's a lot of either empty or preallocated space. Thinking
somehow=3D20
the high-water mark was the culprit, I manually truncated the table
before=3D20 they reran their job. =3D20

Still the same problem. =3D20

If the job runs in 'normal' mode, which is row-by-row processing, it
runs fine,=3D20 although of course, performance is quite poor.

FAQ is at http://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_at_freelists.org put

FAQ is at http://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_at_freelists.org