今年强制自己每月至少发帖一篇，必须是自己做实验之后的内容，还不可以转载，今天是补发1月份的量。。。
一致对 与解决简单死锁的问题没有自己亲手做过实验，每次出问题都是现场百度查看语句，大的方向步骤都知道，查看语句是发生了什么锁，是哪个操作和当前操作发生资源争夺，选择一争夺的一方将它杀掉。总的来说就是这样，现在就详细说说处理过程吧。
打开一个sqlplus端口，以用户scott登录执行以下语句select * from emp for update;再开一个sqlplus端口，同样以scott用户登录，执行update emp set job='HR';执行完后，第二个语句就hang住了。过程如下所示：
于是乎，我们来看看是谁导致了第二个窗口操作被阻塞呢
使用以下语句来查找阻塞的原因:
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 %';
执行结果如下图所示：
通过上图，我们可以发现，被阻塞的语句sid为133，被阻塞的事件是发生了行级锁，那么我们接下来就要找出，是谁占用了表emp的资源导致当前语句发生了阻塞。
我们使用以下语句来找出是谁阻塞了133：
select sid,inst_id,blocking_instance,blocking_session from vg$session where sid=133;
查询结果如下图所示：
从上图可以看出，造成133号进程阻塞的进程是25。
到目前为止，我们就已经知道是谁占用资源导致死锁了，那么现在问题来了，我们是否要杀死进程25来释放资源呢？
最简单的就是直接杀死进程25，方法如下所示：
杀死25号进程之后，第二个端口的更新操作就能成功执行了。
在实际生产中，不仅要找到造成阻塞的进程，而且要慎重决定处理阻塞的方法，不能轻易的就杀死任何进程。
