RE: Informatica Bulk Mode behavior
- From: "Mohan, Ross" <RMohan@xxxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 22 Apr 2004 16:28:51 -0400
Whereas with regular indexes they don't take space? ;-)
Believe if you have, as one example, a FULLY packed, fresh
index on tab(col) with pctfree 0 and defaulted freelisting
and add a few thousand rows via APPEND you are going to get
the same resultant index size if you added the rows via
conventional means.
...your experiences may well be different, but....just a wayt
of saying that mostly the pctfree of the idx and its freelists
config will drive a lot of the space (mis?)usage.
HTH
-----Original Message-----
From: Rajesh.Rao@xxxxxxxxxxxx [mailto:Rajesh.Rao@xxxxxxxxxxxx]
Sent: Thursday, April 22, 2004 2:34 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Informatica Bulk Mode behavior
One thing of note that I have encountered with Direct Load Inserts is that
the Indexes on the table will require twice the space. Say, you have indexes
of size 2 Gb, then after the direct insert, the exisiting index is merged
onto a "temporary" segment along with the new index keys. So, check if you
are running out of space coz of the indexes.
Regards
Raj
"Khedr, Waleed"
<Waleed.Khedr@xxxxx To:
<oracle-l@xxxxxxxxxxxxx>
OM> cc:
Sent by: Subject: RE: Informatica
Bulk Mode behavior
oracle-l-bounce@fre
elists.org
04/22/2004 01:22 PM
Please respond to
oracle-l
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.
----------------------------------------------------------------
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
-----------------------------------------------------------------
Other related posts:
