复杂的故事简单说，复杂的问题简单做，您好，这里是简露一手，欢迎浏览。
简述
16-7月，一大型在线业务系统服务器突然一个个挂掉，重启后不到撑不到五分钟就牺牲，导致生产系统业务故障
oracle锁
定位
因所有应用都有问题，且在未发布版本情况下突然发生，预备进行三个步骤排查定位。
检查数据库情况.
检查服务器日志.
检查服务器网络情况.
数据库情况
这里不说其它的检查项，直奔这次事因：“数据库锁”。
根据经验，我们进行了数据库锁的检查，幸运的是直接找到了问题点。
有一个业务表锁的数量超过100，根据sql_id找出了所有sql，发现了全表锁和锁全表语句，是一条更新全表的update语句。
查询锁：select object_name as 对象名称,s.sid,s.serial#,p.spid as 系统进程号,s.SQL_ID from v$locked_object l , dba_objects o , v$session s , v$process p where l.object_id=o.object_id and l.session_id=s.sid and s.paddr=p.addr;
查询锁表的语句：select * from v$sql where sql_id='65gmqgahz6jp8'
处理
锁一旦出现 ，最简单的办思路就是杀[kill]。
kill 分两种：
oracle 命令kill
ALTER SYSTEM KILL SESSION 'sid,serial#';后台杀oracle语句kill
kill -9 spid
<small>sid,serial#,spid 取值于 查询锁查询结果。
开始杀
首杀
使用[oracle 命令]kill后 新的锁又多了起来，改用[后台杀]kill后，新的锁仍在继续。
再查
分析锁全部的update语句会话是oracle自己产生的，来源于存储过程的概率比较大，在排查存储过程中找到了它，并根据它找到了一个job，是job的重复执行 导致了全表锁的不断产生。
二杀
删除job后重新kill,第二次杀进程后,情况并没有好转,没有了全表锁，但是行锁仍然多，问题变得更为复杂。
再查
经过漫长的分析百种尝试，最终找到来问题.这是一个大意遗漏的点。生产机器一般做了rac，有多个实例，通过tns连接过去的会话一直在一个实例上，查看锁情况始终只查看了一个实例的锁情况，而oracle的job执行 在两个实例上都有可能存在。修改tns地址为第二个实例后，在第二个实例上找到了好几个全表锁的进程。
三杀
登陆到第二个实例上，kill掉锁的进程后1分钟不到，所有的锁都降下去了，重启应用，恢复正常。
总结
事情错综，所以总结一下为两点来将整体内容再简化一下。
因: 生产业务表在业务繁忙期间执行了全表更新语句，与应用上更新单条记录的进程形成循环锁、阻塞，导致整体应用和数据库问题。所以，生产业务表在业务繁忙期间应禁止执行全表更新语句。碰到必须在业务期间全表执行则需采用分批更新和提交,来减小冲突的产生概率，这里说的全表更新包括更新语句没有where条件和where条件的结果有大量数据的两种情况。
果: 找出所有锁，杀掉所有锁。需要注意的是：Job会不停产生更新任务。生产环境一般都做了rac,需检查数据库的多个实例，都进行kill。
实际上这次事故处理时间有点长，中间停起应用、分析日志这些都有做，还有迁移接口、排查代码这些，处理的内容也相当多。回想起来做的事情就一项是有用的：找到所有锁，然后kill。
作者：georgekaren
链接：https://www.jianshu.com/p/f84a6b7ef195
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
随时随地看视频
