警示：一个update语句引起大量gc等待和业务卡顿

墨墨导读：业务卡顿异常，有几个 insert into 语句的gc等待比较严重，发生业务超时，本文分析了超时原因并详述整个处理过程，希望对大家有帮助。

1. 故障现象

客户报2020年7月9号，8点30分左右业务卡顿异常，有几个 insert into 语句的gc等待比较严重，发生业务超时，需要紧急分析一下超时原因，并给出处理建议。

2. AWR分析

由于是业务卡顿分析，可以让客户配合出各节点实例的awr报告辅助分析，另一方面同时进行分析ASH信息：

可以看到gc等待排第一位，等待次数异常高。

可以看到gc等待主要是由3个insert into语句产生的。

3. 诊断分析及建议

首先先备份ASH表，避免数据被刷出内存：

from gv$active_session_history
 where sample_time >=
       to_date('2020-07-09 08:00:00', 'yyyy-mm-dd hh24:mi:ss')
   and sample_time <
       to_date('2020-07-09 10:00:00', 'yyyy-mm-dd hh24:mi:ss')

其次查询各实例按分为统计单位的等待次数趋势情况：

可以发现实例1并没有等待暴增的情况，而实例2在8：30时等待暴示，进一步查询实例2等待次数变化情况：

  from gv$active_session_history
 where sample_time >=
       to_date('2020-07-09 08:00:00', 'yyyy-mm-dd hh24:mi:ss')
   and sample_time <
       to_date('2020-07-09 10:00:00', 'yyyy-mm-dd hh24:mi:ss')
   and event is not null
   and inst_id=1
 group by event
 order by 2 desc;

可以看到确实是节点2的GC等待很严重。

进一步查询gc等待严重的sql语句是哪些：

可以看到这三个gc等待严重的SQL语句都是insert into语句，且是插入同一个表。这里和AWR的分析相吻合，进一步查询gc使用块类型占比，考虑如果被用于撤销块比例过多，则应用实例划分可以大大降低GC传输。

  trunc(data_requests / decode(tot_req,0,1), 2) *