生产环境：数据库：  Oracle 10.2.0.4  2Nodes RAC

操作系统：AIX 5309

故障现象：

现象1：在23日上午11:30，发现应用系统不能连接到RAC的实例1（Instance name:int1），此时实例2是正常的。

现象2：使用辅助工具TOAD也不能连接到实例1。

现象3：在实例1所在机器的本地使用SQLPLUS可以连接到实例1，此时也能在实例2上通过TNS连接到实例1。

现象4：15：19重启实例1后系统恢复正常。

故障分析：

1.根据实例1的alert log日志记载，在11：30记录的错误如下：

Tue Mar 23 11:30:08 2010

WARNING: inbound connection timed out (ORA-3136)

Tue Mar 23 11:32:05 2010

WARNING: inbound connection timed out (ORA-3136)

首先来了解ORA-3136这个错误，该错误表示客户端在sqlnet.ora文件中SQLNET.INBOUND_CONNECT_TIMEOUT参数定义的时间内没有完成登录认证，该参数默认值为60S，据Oracle官方文档记载，此默认值能够满足绝大多数条件；此外该错误还涉及到listener.ora文件中定义的参数INBOUND_CONNECT_TIMEOUT_LISTENER，Oracle 10.2.0.1之前默认值为0，从10.2.0.1开始默认值为60S，根据alert log日志记录的其它信息，目前暂时排除实例1的错误是由以上参数造成。

2.Alert log还记载

……

Tue Mar 23 12:15:36 2010

Errors in file /soft/oracle/admin/int/udump/int1_ora_2617378.trc:

ORA-00600: internal error code, arguments: [12333], [7], [2], [49], [], [], [], []

……

根据Oracle metalink文档[ID 35928.1]描述：“Fatal Two-Task Protocol Violation”

ORA-600 [12333]描述收到一个没有经过验证的无效的网络数据包，这里有二个可能：一是客户端多线程的应用发送了一个无顺序的OCI调用请求，二是网络缓冲区中的数据可能被覆盖，进一步查看trace文件，可以看到每个trace文件的开关处都有：PROTOCOL VIOLATION DETECTED。

另外，由贵行的带内网管软件Tivoli监控到故障当时RAC心跳网络（ent8）的通信流量信息证明，当时心跳网络流量确实比正常情况下高，RAC 采用UDP 协议进行节点间的互联通信，查询系统统计如下：

RACDB1# netstat -p udp -s

udp:

574337869 datagrams received

0 incomplete headers

0 bad data length fields

0 bad checksums

169617 dropped due to no socket

32335 broadcast/multicast datagrams dropped due to no socket

243 socket buffer overflows

574135674 delivered

500048775 datagrams output

RACDB2# netstat -p udp -s

udp:

500187207 datagrams received

0 incomplete headers

0 bad data length fields

0 bad checksums

171357 dropped due to no socket

32333 broadcast/multicast datagrams dropped due to no socket

2108 socket buffer overflows

499981409 delivered

574427147 datagrams output

以上信息可以看到，由于系统网络参数network buffer设置不当出现通信问题，查看涉及network buffer大小的参数：

#no -a |pg

sb_max = 1310720

udp_recvspace = 655360

udp_sendspace = 65536

sb_max被用来指定允许的TCP和UDP socket的最大缓冲区大小，默认值为1048576 bytes，1048576 bytes，很显然，udp_recvspace与udp_sendspace设置不对称且sb_max参数设置过小。

3.ORA-600 [12333]的错误也可以由JDBC驱动版本与Oracle数据库版本不一致造成，但贵行此套系统已上线很久，由此可以暂时先排除该原因。另外，根据trace文件的记录，在故障期间有大量的UNION联合查询操作，而这种大量的UNION操作会增加节点间的通信，ashrpt的报告也证实了gc buffer busy随故障时间增加，到最后被剔出RAC降下来。

初步结论：

基于以上情况分析，现初步判断此次故障为：由系统网络buffer参数设置不当引起RAC 节点间的互联网络故障，而节点间的互联网络用于协调各个节点的运行，包括全局锁(global locking) ，队列(enqueue) 和缓存管理(buffer cache management)，建议udp_sendspace 的起始值为db_block_size * db_file_multiblock_read_count ，udp_recvspace 设为udp_sendspace 的4 倍，上限为1048576 。如果发生socket 缓存溢出( 可通过 netstat -s | grep “socket buffer overflows” 命令察看) udp_recvspace 参数值需要增加，netstat -p udp -s的结果也证实了这一点。

BTW:这里还有EYGLE大师的文章供参考：

IBM AIX Oracle 9i RAC 性能因素 – udp及其他

-The End-

您可能也喜欢：

AIX下使用 raw 创建 non-rac 的ASM

ORA-00600:[2103],[1],[0],[1],[900]的处理

RMAN ORA-19504、ORA-27038错误解决方法

ORA-12547: TNS:lost contact

无觅