简单的死锁处理过程

今年强制自己每月至少发帖一篇,必须是自己做实验之后的内容,还不可以转载,今天是补发1月份的量。。。

一致对 与解决简单死锁的问题没有自己亲手做过实验,每次出问题都是现场百度查看语句,大的方向步骤都知道,查看语句是发生了什么锁,是哪个操作和当前操作发生资源争夺,选择一争夺的一方将它杀掉。总的来说就是这样,现在就详细说说处理过程吧。

打开一个sqlplus端口,以用户scott登录执行以下语句select * from emp for update;再开一个sqlplus端口,同样以scott用户登录,执行update emp set job='HR';执行完后,第二个语句就hang住了。过程如下所示:

简单的死锁处理过程_第1张图片

于是乎,我们来看看是谁导致了第二个窗口操作被阻塞呢

使用以下语句来查找阻塞的原因:

select sid,event,username,sql.sql_text
from v$session s,v$sql sql
where s.sql_id=sql.sql_id
and sql.sql_text like 'update emp set job %';

执行结果如下图所示:

简单的死锁处理过程_第2张图片

通过上图,我们可以发现,被阻塞的语句sid为133,被阻塞的事件是发生了行级锁,那么我们接下来就要找出,是谁占用了表emp的资源导致当前语句发生了阻塞。

我们使用以下语句来找出是谁阻塞了133:

select sid,inst_id,blocking_instance,blocking_session
from vg$session
where sid=133;

查询结果如下图所示:

简单的死锁处理过程_第3张图片

从上图可以看出,造成133号进程阻塞的进程是25。

到目前为止,我们就已经知道是谁占用资源导致死锁了,那么现在问题来了,我们是否要杀死进程25来释放资源呢?

最简单的就是直接杀死进程25,方法如下所示:

简单的死锁处理过程_第4张图片

杀死25号进程之后,第二个端口的更新操作就能成功执行了。

在实际生产中,不仅要找到造成阻塞的进程,而且要慎重决定处理阻塞的方法,不能轻易的就杀死任何进程。

你可能感兴趣的:(简单的死锁处理过程)