大量latch:undo global data的争用，导致数据库整体性能下降
现象错误号
数据库整体响应下降
故障描述
本文档主要针对某客户核心系统早上6点55分左右出现性能异常，应用响应超时持续长达10分钟，询问后得知由于双十一，日结推迟两小时，完成时间为11号早上7点。在仔细诊断过程中，结合相应时间段的Oracle性能报告，定位相关SQL，最终结论为同时高并发的insert和delete相同表格ACCOUNT_JNLS引起大量latch:undo global data的争用，导致数据库整体性能下降。具体分析如下。
故障原因分析
ASH 报告对比
数据库整体会话数
11 月9、10日6:50:~7:00
11 月11日6:50:~7:00
从数据库整体会话数看 11 号当天明显高于 9 、 10 号两天，近 5~6 倍。
11 月9、10日6:50:~7:00
11 月11日6:50:~7:00
从数据库Top User Events来看11号当天等待事件相对于9、10号两天较为异常，数据库大部分等待都花费latch:undo global data争用上。
SQL 等待
11 月9、10日6:50:~7:00
11 月11日6:50:~7:00
对比9、10日，11号当天相同SQL语句执行次数明显上升，除此之外 at6cgwnx1ajpb、 6d9shb2ma1f2d两条insert和for update
语句在前两天是不曾出现的并且产生了大量的latch: undo global data、enq: TX - row lock contention等待,占据了整体的40%之多。
备注： at6cgwnx1ajpb对应SQL语句INSERT INTO account_jnls ( serial_no , account_jnls_no , trans_jnls_no ,……)
6d9shb2ma1f2d 对应SQL语句SELECT area_code , account_no , product_code , gl_class , virtual_flag , real_flag , collect_flag , balance_type , balance_ctrl , sync_flag , cur_type , spot_type , close_flag , max_acc_cycle_no , max_clearing_times , dayend_cycle_no , TO_CHAR(acc_date, :"SYS_B_0") , TO_CHAR(last_acc_date, :"SYS_B_1") , TO_CHAR(open_date, :"SYS_B_2") , TO_CHAR(close_date, :"SYS_B_3") , detail_cnt , debit_amt , credit_amt , debit_cnt , credit_cnt , balance , pre_clearing_times , pre_times_balance , pre_times_dcnt , pre_times_damt , pre_times_ccnt , pre_times_camt , pre_cycle_no , pre_balance , pre_debit_cnt , pre_credit_cnt , pre_debit_amt , pre_credit_amt , dac FROM account_dynamic WHERE account_no = :account_no__0 FOR UPDATE
结合ash报告初步判定由于并发insert引起大量latch:undo global data的争用，但是理论上单一insert是不会引起undo争用，进一步排查awr。
AWR 报告对比
数据库top 5
11 月9、10日6:00:~7:00
11
月11日6:00:~7:00
从数据库整体awr报告来看出现了异常latch: undo global data等待，DB CPU所占的时间也从原来的50%左右下降到30%。
TOP SQL
从AWR latch: undo global data 为数据库TOP 5 wait event, 查看了该语句就是一条简单的insert values语句（9、10日的报告中并未发现相同SQL），执行频率每小时63620次，单条的执行速度还可以，但是为什么会这么多的latch undo 呢？
进一步查看undo相关的latch
KSLBEGIN 是一种get latch时的非常快的宏，在取得latch后调用KSLEND，ktudba 像是一种从usn 转换data block address的宏
@ Latch Miss Sources
@ ——————
@ undo global data ktudba: KSLBEGIN 0 117,271,003 115,396,045
@ .@ .@ ktu.h:
@ ——
@ #define ktudba(usn, dbap, scnp, arspp) \
@ ktuGetUsegDba((usn), (dbap), (scnp), (arspp), \
@ NULLP(ub2), NULLP(ksqn), NULLP(uword))
@ .
@ ktuGetUsegDba – Kernel Transaction Undo convert from usn to DBA
从latch统计来看存在争用，并非insert单独引起，此时猜测相同表格上存在delete操作，进一步查看sql统计部分，如下：
此时相同表格上确实存在delete操作，通过SQL*Plus客户端连接执行。到此时整个现象已经很明显了
故障总结及建议
综合上述分析判断，本次性能故障主要原因是相同表格上同时执行delete和insert操作引起latch:undo global data争用，导致整体性能下降。建议排查应用是否由于日结延迟引起此类问题的出现。