Archives of the TeradataForum
Message Posted: Fri, 01 Jan 2010 @ 18:53:20 GMT
| Subj: | | Re: Row Hash Deadlock in Active D/W due to concurrent MSR |
| |
| From: | | Victor Sokovin |
| | Thank you for your suggestions. Using my case(query#1 and query#2), can you please elaborate further on the lock escalation/changing the
order in the MSR part(perhaps with a simple example)?. | |
I was referring to Carrie's remark which implied that locking in MSR may change depending on on whether the statement is the last or not:
"There is only one exception still remaining that I am aware of. That is the case where you have a macro or a multi-statement-request with
mixed row-level modifiers (some access, some read). If the row level access lock statement is not last in the MSR or macro and the final statement
takes the default read lock modifier, then the row level access lock will be converted to a row level read lock."
Just try to put your update as the last statement in MSR and see whether that makes any difference. If it is indeed the last one then try the
other scenario :-) These experiments should not take much time but may add some information.
| | How can lock escalation cause a deadlock? | |
Well, that was my guess. As I said, I cannot understand how a deadlock can occur if both transactions are trying to acquire the row hash lock.
It's just too simple a case to create any deadlocks. When the locking escalates to table level there are more possibilities for confusion.
| | Further, how does changing the order help? | |
See above.
| | Also, would anyone know why sometimes the locking logger is unable to capture the lock data even though the transaction aborts due to
deadlock? | |
This probably suggests that the case you are looking at is a bug. Mysterious deadlock, no logging. Getting Teradata Support to look at the case
may be in order.
Victor
| 
