Archives of the TeradataForum

Message Posted: Sat, 02 Jan 2010 @ 09:46:20 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Hello Victor,

We shall check with the TD support team to investigate the issue further. You're right. Changing the order can be done to see if we get some success in debugging this issue. This won't take much time.

Some questions for you and all other experts....

As I said before, the table on which deadlock occured has an NUPI. Suppose that we have 5 rows for a particular NUPI value that need to be updated by 2 concurrent updates(that are PI based 1-amp operations)

Could the deadlock occur because one update acquired a R-H Lock on only 2 rows, and while it was trying to acquire the same lock on the rest of the 3 rows, the other update came into picture and acquired the same lock on the other 3 rows.

This means that update#1 is waiting for the lock to be released on the 3 rows acquired by update#2 and update#2 is waiting for the lock to be released by update#1 on those 2 rows. A perfect deadlock situation where the younger request will fail after a stipulated time period. Is this possible?

I am asking this question because only this scenario fits well with the locking logger that we have captured.

Will changing from NUPI to UPI help? I can probably go back and analyse the table to add another column to the existing NUPI to convert it into a UPI.

Also the MSR's will be changed so that rather than having one update statement that updates few rows of a table based on a NUPI value, we will have a few more UPI-based statements , every statement updating 1 and only 1 row of the table.

Regards,

-Suhail

	<Prev	Next>		<<First	<Prev	Next>	Last>>