有时间的业务锁死也许与死锁无关，因为即使没有任何业务，你自己的流程也会卡死

往往我们遇到性能问题，都会考虑到互相之间的资源争用，但是有时也许是业务本身的卡住了

最近市局制卡遇到这么个奇葩案例：

查找结果 1: 顶级 SQL 语句
受影响的是 10.7 个活动会话, 占总活动的 64.3\%。
-------------------------------
发现 SQL 语句消耗了大量数据库时间。这些语句提供了改善性能的绝佳机会。

   建议案 1: SQL 优化
   估计的收益为 5.75 个活动会话, 占总活动的 34.58\%。
   ---------------------------------
   操作
      研究 UPDATE 语句 (SQL_ID 为 "8kjryk90wdm1y"), 确定是否可以改善性能。可以利
用此 SQL_ID 的 ASH
      报告来补充此处给出的信息。
      相关对象
         SQL_ID 为 8kjryk90wdm1y 的 SQL 语句。
         UPDATE CC_AZ20 SET AAZ500 = :B2 , BAZ023 = ENCRYPT('123456') WHERE
         BAZ849 = :B1
   原理
      SQL 在 CPU, I/O 和集群等待上花费的时间只占其数据库时间的 0%。因此, SQL 优
化指导不适用于这种情况。请查看 SQL
      的性能数据以找出可能的改进方法。
   原理
      此 SQL 的数据库时间由以下部分构成: SQL 执行占 100%, 语法分析占 0%, PL/SQL
执行占 0%, Java 执行占 0%。
   原理
      SQL_ID 为 "8kjryk90wdm1y" 的 SQL 语句执行了 12 次, 每次执行平均用时 16683
秒。
   原理
      等待事件 "enq: TX - row lock contention" (在等待类 "Application" 中) 消耗
了数据库时间的
      100% (该数据库时间为处理具有 SQL_ID "8kjryk90wdm1y" 的 SQL 语句时所用的时
间)。
   原理
      执行 PL/SQL 语句 (SQL_ID 为 "43nra4y8hc85w") 的顶级调用占数据库时间的 100%
, 该数据库时间是花费在
      UPDATE 语句 (SQL_ID 为 "8kjryk90wdm1y") 上的时间。
      相关对象
         SQL_ID 为 43nra4y8hc85w 的 SQL 语句。
         BEGIN PKG_CC_卡中心入口.PRC_小型制卡机生成制卡数据(:1 ,:2 ,:3 ,:4 ,:5 ,
:6 ); END;

我rac两节点查锁

select inst_id,session_id||',' from gv$locked_object where object_id in (
select object_id from user_objects where object_name='CC_AZ20') and inst_id=1;
select inst_id,session_id||',' from gv$locked_object where object_id in (
select object_id from user_objects where object_name='CC_AZ20') and inst_id=2;

杀了后， UPDATE CC_AZ20 SET AAZ500 = :B2 , BAZ023 = ENCRYPT('123456') WHERE
         BAZ849 = :B1可以过去了，结果第二天又出来了一批

select a.INST_ID,sid,a.status,a.INST_ID,
      'kill -9 '|| b.spid||'' from gv$session a,
       gv$process     b           where (sid) in (3764,
3549,
3542)     and    a.INST_ID=1  
            and (b.addr = a.PADDR );

select a.INST_ID,sid,a.status,a.INST_ID,
      'kill -9 '|| b.spid||'' from gv$session a,
       gv$process     b           where (sid) in (3764,
3549,
3542)     and    a.INST_ID=2 
            and (b.addr = a.PADDR );

然后让前台停止业务办理，单个业务跟踪，发现居然卡在一个select   sys_lob上

最后发现这个表上是一个需要定期导入可用号段的表，号段可用没了，所以卡助了

只能嘲笑一下开发，这代码合适么