说明

上周末一个重要系统出现了问题导致rac重启，影响了业务，因此记录一下解决过程。

环境

搭建平台：VMware Workstation

OS：RHEL 6.10

Grid&DB：Oracle 11.2.0.4

问题描述

上周末下午数据库的会话数突增，导致数据库节点一进程数满了，应用新的会话连接节点1报错，alert日志中出现大量的ORA-00020报错，直到30分钟后节点一实例重启，随后数据库恢复正常。在这期间影响了多笔重要业务。

分析过程

alert日志显示最大进程数用尽，出现ORA-00020的反复报错，此时数据库已经发生阻塞，导致节点一实例process用尽。

ASH发现16:21开始1#会话突增,16:22开始2#实例突增：可以看出是1#节点先出现问题，随后导致2#实例的会话数突增。

发现16:21:02开始出现等待enq: US – contention，16:21:12  1#出现12个ens: US等待，随后出现enq: SV -contention:

注：

enq: US – contention是事务出现undo segment不够时需要申请新的undo segment产生的阻塞

enq: SV – contention是获取sequence number而产生的阻塞

查看对应的SQL ID发现都是DML操作：

查看awr报告：

1. 发现相关SQL和两个sequence有关，于是查看这些sequence的定义后发现了两个问题：

（1）有order关键字，会导致RAC环境操作进行2个节点的同步处理

（2）Cache过小

因此enq: US – contention和enq: SV – contention等待是相关关联的，enq: US 阻塞会导致包含sequence nextval的DML无法提交，导致sequence更新cache失败；而enq: SV -contention阻塞也可能导致sequence更新慢，DML操作缓慢。

2. AWR发现故障之前最大并发事务100左右，因此ONLINE的undo segment可能在100左右，但是故障时两个问题SQL的确出现了接近200的并发session，并且二节点当时也有少量并发sql。同时查看两个节点的历史最大会话数在2千多

综上分析，本次故障原因是突增的并发DML语句，导致online undo segment不够，当online扩展undo段时产生阻塞，并且相关问题SQL的sequence使用order模式，会导致顺序同步争用，跨节点操作更严重。

解决方法

1、按关闭自动undo管理，并设置足够的online回滚段:

alter system set "_rollback_segment_count"=3000;

alter system set "_undo_autotune"=FALSE;

2、 修改sequence cache到10000，取消order，减少数据字典更新频率及同步：

alter sequence XXX1_SEQ_S cache 10000 noorder;

alter sequence XXX2_SEQ_S cache 10000 noorder;

3、为避免跨实例同步，使应用连接同一个实例