我们有一个数据库正在“放缓”的情况。 通常需要一两秒钟的数据库操作需要十倍的时间。 发生这种情况时，数据库中似乎有大量的锁。 大量的死锁是否会造成数据库广泛的缓慢？
死锁是一种特殊情况，事务A有一个锁，然后试图locking当前被事务Blocking的东西，必须等待。 然后，事务B试图locking当前由事务Alocking的项目。数据库'注意到'情况不能自然地解决，所以错误事务之一并迫使它回滚。
正如其他人所说，这是不寻常的，我希望你会有关于僵局申请的错误的报告。
相反，我猜测“事情”已经改变了。 它可能是锁，但同样可能是因为事务需要更长时间（因此锁保持更长时间），所以locking更多东西。
如果您使用AWR / ASH（Diagnostics / Tuning Pack）的10g / 11g，则OEM应该能够帮助诊断情况。
如果没有，看看V $ SESSION，看看是否有很多与BLOCKING_SESSION设置的会话。 这表明他们正在等待locking。 你只需要担心会话等待的锁，所以使用这个而不是锁的数量。 如果这并不意味着问题发生在v $ session_event上，并查看大部分时间内wait_class条目是由什么负责的。
这可能是死锁，但是数据库通常可以知道什么时候存在死锁，并且会在这种情况下终止具有死锁exception的连接。
我已经在oracle数据库中看到过这种情况，并且在资源稀薄的情况下可能会发生这种情况，并且数据库内存不足，必须交换到磁盘。
如果大量作业都在队列中等待相同资源释放，那么情况尤其如此。
死锁被logging在跟踪文件中，所以你可以很容易地判断这是否是问题。 首先分析通常的嫌疑人。 查询解释计划，索引，统计等。