天道酬勤

故障日期：2010年3月23日 11:30 AM

生产环境：数据库：  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-

很久没有更新博客了，当大家看到这个标题的时候可能会怀疑我是不是提前到了更年期了，我不知道男人到了40的年纪是不是也会有像女人一样的征兆，姑且认为差不多吧。

近段时间很忙，因为公司是IBM合作伙伴，为了获得承接某些项目的资历，大家都不断的学习考试，而我选择了102－IBM Certified Systems Expert – High Availability for AIX Technical Support and Administration，虽然IBM的考试不贵而且公司还报销，但是看到在前面考试的兄弟挂了压力还是蛮大的。目前公司的业务主要在小机和存储这边，数据库的业务少一些，由于以前没有怎么接触过小机，所以要恶补这方面的知识，但我又是那么那么的迷恋数据库，我又怎么可能放下呢！看书，看文档，实验一个都不落下。为了能与时俱进，出差前还是考了1Z0－040，12日途经武汉到宜昌，某电力公司系统扩容：2台P670做的HA、ORACLE数据库、CPU从4Way升到8Way、MEM从16G升到32G、磁盘增加一个T；客户的业务是不能停的，加上这种老机器拆装CPU风险高啊。实施之前查看环境做好备份，从13日周六开始干活到14日凌晨3：30，回到酒店洗完天都快亮了，中途实在是顶不住了趴在一张桌子上睡了会儿，哪知这一趴就一个小时，完全没有感觉到机房的寒冷。大公司机房多，有处理业务的系统，有监测水文、天气的系统，本人这次有幸到了那雄伟大坝的心脏，感受到了什么才叫专业级的监控，cool,very cool！结束了在宜昌五天的工作，下一站：黄石－鄂州－南昌，就这样不停的赶路－投店－机房的生活让人有点累，特别是到了晚上，想念老婆还有果果（他/她现在还在老婆肚子里面），屈指算算，有10天她没有听到我讲的睡前故事了，没有给她按摩了，不知道小家伙有没有想我呢！脑海总会想像她的可爱，她的调皮，我该买个什么样的相机去珍藏那一刻：卡片的太单调能突显她吗？单反的操作会不会太复杂我捕捉不到那一刻，或许那个时候看到她我就不觉得累了。昨天早上终于回到深圳了，快点回家赶在老婆七点出门上班，洗手消毒去摸摸她的肚子，9天肚子变大了一些，嘿嘿！洗澡、刮胡子、剪指甲，发现睡不着，去楼下剪头发，吃饭，睡觉，电话，电话，睡不着起床，等老婆下班回来跟果果说话。晚上十点，眼看就要恢复中断了9天的睡前故事，电话响了（技术部老总的）：

总：现在在哪儿呢？

我：今天早上回来的。

总：那正好，你现在马上到xxx来吧，客户(其实现在还不是我们的客户)的一套RAC系统出问题了。

我：好，就来。

背电脑、下楼、打车，经过重重安检11：00到达客户机房，了解情况：客户是一套双节点的10.2.0.4的RAC加二套DataGuard，在做了灾备演练failover后，一节点起不来了，alert*.log出现ORA-16009 in alert log with standby and LGWR ASYNC的错误，检查DG的配置信息：

log_archive_dest_2设置有VALID_FOR=(ONLINE_LOGFILE, PRIMARY_ROLE)

这个错误在metalink描述为一个Bug 4676659

ID 4676659.8

客户的版本正好在受影响版本的范围。

最后决定，暂时在standby上取消远程归档路径：

SQL>alter system SET log_archive_dest_2 = ''

$ srvctl star instance  -d intrac -i int2
$ srvctl status database -d intrac -v

至此，RAC系统恢复正常，此次故障究竟是否是碰到了BUG，还需要进一步的检查和测试来定案。
回到家，老婆早已经睡了，但她说了一句：老公回来了。躺床上久久不能久睡，思维还留在ORA-16009的一些疑问中，唉，又要失眠了。早上老婆问我是不是又3：30回来的，我说很早就回来了，0：30。

-The End-

最近一老失眠，今儿一大清早就爬起来上网，从google的订阅服务得知：由EYGLE与KAMUS二位大师发起并成立了中国Oracle用户组ACOUG（All China Oracle User Group）。届时，越来越多的数据库爱好者、Oracle爱好者将会出没这里。well，so……一线民工以此博文当贺电来表达喜悦心情，各位工友欲知更多详情请参考官网，谢谢!

-The End-

Wow，昨天在Eygle大师的Blog上看到《Oracle DBA手记》已经上架了，先恭喜一下这几位大牛（Eygle、Yangtingkun、老熊、zergduan、banping）出了新作。继续往下看，没想到第一本书是寄给我的，这里谢谢Eygle，谢谢几位大牛们，感谢Julia，因为我想大师业务缠身应该没有时间寄书：）。农历新年快到了，这本书对我来说是新年最好的礼物，同时也是莫大的鼓舞，告诫自己努力。图片作证：

-The End-