问题描述
数据库出现性能问题，应用响应超时持续长达10多分钟。由于每秒有大量insert，业务实时敏感性较高，而且每天凌晨会对前一天的数据进行归档也就是insert进历史表格，原表数据会进行delete清理（数据量每天300W左右）。平时这一步都能顺利完成。而故障当天业务部门由于某种原因异常终止了delete，这异常终止导致了后续出现了短暂的卡顿。
分析过程
根据上面的信息：大表delete被异常终止后出现短暂性能卡顿。我们知道大型DML被终止后smon进程会做大事务回滚，对应的数据库等待事件为：wait for a undo record，其中fast_start_parallel_rollback参数决定了SMON在回滚事务时使用的并行度。当前参数值为LOW，也就是2*CPU_COUNT数目的并行度回滚。可想而知此CPU使用率会明显上升，监控平台印证了这一点，持续时间刚好覆盖了故障时间段。
获取故障时间段AWR报告：
从数据库Top events来看故障时间等待事件明显异常，数据库大部分等待都花在：latch:undo global data、enq: TX - index contention以及wait for a undo record争用上。其中wait for a undo record由于并行回滚所致。
知识扩展：
enq: TX - index contention：索引争用、索引块分裂直接相关，当一个事务需要向一个数据块插入数据时，该数据块正好发生了索引分裂，则插入事务需要等待分裂事务。通常发生在高并发的OLTP系统中。
latch:undo global data：对SGA中撤消（也称为回滚）段信息的访问，每次会话获取撤销段状态时，都必须获取此闩锁。
根据扩展知识enq: TX - index contention由于高并发的insert所致，这里不做过多阐述。
这里我们重点分析下latch:undo global data
从ASH统计来看，不同的会话在同一条INSERT SQL语句出现了较高的latch: undo global data 等待，latch miss是 ktudba: KSLBEGIN ，同时伴随着大量buffer busy waits等待（经确认insert都为该业务发起）。
AWR latch: undo global data 为数据库TOP 1 wait event, 同时确认了ASH是一条简单的insert values语句，由于该应用未使用绑定变量执行频率从AWR 无法获取，但从沟通中可以确认是执行频率相当高，但是为什么会这么多的latch undo 呢?
latch争用，并非insert单独引起，此时猜测相同表格上存在delete操作，进一步查看ASH统计部分，如下：
|
|
其中49vuyv41gxzyu引起了我的注意（delete from Cur_Flow_Search where substr(O360SEQ,5,8) <'20191218'），执行时间刚好故障发生前后，与应用确认后正是他们异常终止的delete操作。发现blocking_session为空没有被堵塞。进一步查询该语句是否阻塞了其他会话：
|
再进一步使用上图中的sid作为blocking_session排查：
省略部分……
|
现在已经明确了是sid=2845的会话做了一个delete 大表操作， 直接或间接堵塞了该业务大量insert操作。
总结：
本次性能故障主要原因是大表delete被异常终止，引起大事物回滚，系统资源开销上升，间接影响了相同表格上其他insert操作，引起latch:undo global data争用，导致该业务模块性能下降。
所以，对于大事物回滚建议将系统参数fast_start_parallel_rollback修改为false,关闭并行恢复，减小高峰期系统资源争用。
另外该业务表格存日期字段o360seq为varchar类型，而且此字段含有主键索引、联合索引多达3个，但实际上删除中条件使用了函数，索引并未产生作用。建议该字段建成data类型字段，减少条件字段使用函数。
大表删除数据时建议用存储过程或函数，批量提交，避免删除数据量过大导致undo暴涨及争用情况发生。
