往往我们遇到性能问题,都会考虑到互相之间的资源争用,但是有时也许是业务本身的卡住了
最近市局制卡遇到这么个奇葩案例:
查找结果 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上
最后发现这个表上是一个需要定期导入可用号段的表,号段可用没了,所以卡助了
只能嘲笑一下开发,这代码合适么