说明
上周末一个重要系统出现了问题导致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、为避免跨实例同步，使应用连接同一个实例
