Tag Info

New answers tagged

3

No, your case does not block on Oracle, nor should it. Concurrency is one the the major reasons to use an RDBMS instead of say, Excel. But just to make it interesting, if you insert the same value in both sessions, it will then block. Session #1 CREATE TABLE t1 (c1 NUMBER PRIMARY KEY); INSERT INTO t1 VALUES (1); -- do not commit transaction Session #2 ...


2

I'm answering my own question here because we finally figured out the problem. Short Version: We added a third column to the nonclustered index. Deadlocks disappeared. Long Version: First, check out James Rowland-Jones' dynamite blog post about lock hashing collision (My explanation will be nowhere close to the quality of his). From the blog post: ...


0

I am not sure whether this could actually be answer but I cannot post this as comment so putting this If you see your application code its like @P1 nvarchar(4000) ,@P2 nvarchar(4000), @P3 datetime2, @P4 nvarchar(4000), @P5 nvarchar(4000), @P6 decimal(38,1), @P7 int, @P8 int) INSERT INTO OBC.MBL_CPU_POS_MSR_ATB ( CRT_S, CRT_PGM_C, CRT_UID, LST_UPD_S, ...


2

It can make sense to insert data in order. There's lots of caveats to this though. If the data isn't frequently updated and if you're using certain types of tables or indexes (e.g. IOT, clustered indexes). Being in order means that if you're doing a range scan of the ordered column (e.g. BETWEEN x AND Y) then the data is more likely to be in a ...



Top 50 recent answers are included