问题：为什么我们会收到错误"TT6002：锁请求被拒绝，因死锁而被拒绝"，而我们的SQL主要是对唯一行进行插入和更新？
解决方案
回答：
-
当未提交的值被更新时，优化器会在执行阶段移除该旧值，而不是等待提交时。在这种情况下，用户先插入后再更新。如果更新涉及在并发事务中将索引列更新为相同值，情况也会更糟。
-
执行时从索引中删除需要某种下一锁来保护已删除位置，以备需要回滚时使用。
-
我们有两种机制可以防止随机行的下一轮锁定，具体如下：
a.对于非唯一索引，我们使用通用锁来阻止所有可序列化的扫描
b。对于唯一索引，我们插入一个带有锁
4的假行。在这种情况下，它是非唯一索引，但由于某些并发FK验证需要可序列化扫描，无法放置3.a。结果，我们被迫用下一个锁配合X锁，而X锁是死锁的根源。
以下应用端的变更有助于处理或避免死锁：
-
应用程序在发现死锁时应重试事务，这实际上是 Timesten 的标准和推荐做法。
-
通过将插入+更新合并为一个事务，避免更新未提交的值。
-
避免同时更新索引列到与其已存在的值相同。
这在11.2.2中被注意到，但在11.2.1和7.0中也可能出现。这种死锁在某些情况下是由于上述3级内部导致的死锁情况，因此我们正在修复该漏洞，因为遇到该问题的用户不会做出应用端的修改。这个问题在11.2.2.4.6版本中修复了15941309、16738960和16739014的漏洞。在11.2.2.6.0版本中修复了，作为16805039的bug。这个问题在11.2.2.5.x版本中没有修复，因为11.2.2.6.0会和11.2.2.5.1差不多同时发布。
Summary
Question: Why do we get error "TT6002: Lock Request Denied Because Of Deadlock" when our SQL is mostly inserts and updates on unique rows?
Solution
Answer:
-
When an uncommitted value is updated, optimizer will remove the old value from the index during execution phase instead of waiting until commit time. In this case, user did an insert followed by an update. Situation can also be worse if the update involves updating the indexed column to the same value in concurrent transactions.
-
Delete from the index at execution will require some kind of next lock to protect the deleted position in case a rollback is needed.
-
We have two mechanisms to prevent next locks on random row as follows:
a. For non-unique index, we use a general lock to prevent all serializable scan
b. For unique index, we insert a dummy row with a lock
- In this case, it was a non-unique index but 3.a could not be placed because some concurrent FK verification need serializable scan. As a result, we were forced to use next lock with X lock and X lock is a source of deadlock.
The following application side changes could help handle or avoid the deadlock:
-
Application should retry the transaction when it catches that a deadlock occurs, this is actually standard and recommended practice for Timesten.
-
Avoid updating of uncommitted value by combining insert+update into one transaction.
-
Avoid doing concurrent updates of indexed column to the same value as it already is.
This was noticed in 11.2.2, but can occur in 11.2.1 and 7.0. This deadlock in some cases is the result of internally caused deadlock situation described above as 3, so for that reason we are fixing the bug since the particular users that encountered it would not make application side changes. This was fixed in 11.2.2.4.6 in bugs 15941309, 16738960, and 16739014. It is fixed in 11.2.2.6.0 as bug 16805039. This was not fixed in the 11.2.2.5.x release since 11.2.2.6.0 will come out around the same time as 11.2.2.5.1.