Waleed,
If there is not an uniqueue index, the statement is correct. However with an
unique index and different processes inserting the same unique value, there is
a hang.
The problem is not the table, but the index and adding itl's won't help.
Anjo.
Khedr, Waleed wrote:
It does not look
Waleed,
I will run a script and check for missing indexes.
Thanks,
Cherie
Khedr,
You mention a partitioned table. Not an IOT I hope? Because SELECTs can cause
deadlocks on an IOT if you partition it in the process (deadlock on DDL, as opposed to
DML, locks). I used to have a trigger of death to check it, but I wouldn't recommend
it, since you have to delete SYS tables to
Can you please give more details on: While testing our nightly load job that
runs in two simultaneous
streams (ascending and descending).
What do you mean by descending and ascending (simultaneous)?
Thanks
Waleed
-Original Message-
Sent: Thursday, April 25, 2002 11:19 AM
To: Multiple
Stephane,
No, this is not an IOT table.
This is a TX type of lock on insert.
Thanks for your reply.
Cherie
Stephane
Basically the concurrency level = initrans (so if 2 jobs run - set it to 2),
however for indexes set it to conccurency + 1.
Anjo.
[EMAIL PROTECTED] wrote:
We are testing an upgrade of our warehouse from 8.0.4 to 8.1.7.2.
While testing our nightly load job that runs in two simultaneous
My guess there is no triggers or referential constraints since it's a Data
Warehouse.
More details will help,
Regards
Waleed
-Original Message-
Sent: Thursday, April 25, 2002 12:53 PM
To: Multiple recipients of list ORACLE-L
Is it a TX mode 4 (Share) deadlock ?
Can you post a
Is it a TX mode 4 (Share) deadlock ?
Can you post a section of the deadlock graph
from the trace file.
If you really have only two streams running,
then you need only set initrans to 2 at a cost
of (typically) 24 bytes per block to guarantee
that the problem goes away.
There are several other
Waleed,
There used to be a single process that loaded the data. It ran too long
and the application owners split the job out into two process. One
started at one end and loaded data in ascending order and the other started
at the other end and loaded in descending order.
Both jobs run at
Jonathan,
Following is section of the trace file generated. It is a TX lock. I'm
not sure whether it is mode 4.
How can I tell?
We upgraded using the migration script, not export/import. During the
nightly loads we have
always dropped the indexes on the foreign keys on this large fact
Any unique constraints or primary keys?
-Original Message-
Sent: Thursday, April 25, 2002 3:04 PM
To: Multiple recipients of list ORACLE-L
Waleed,
There used to be a single process that loaded the data. It ran too long
and the application owners split the job out into two process.
It does not look like an inittrans problem on the table.
I remember reading that Oracle will try to avoid contention on itl if it's
doing insert by adding new blocks to the free lists. The only conflict that
could happen on itl (inittrans) during inserts is for indexes.
Could you have a primary
12 matches
Mail list logo
