Oracle and My Life
今天学习了db_files和maxdatafiles两个参数，记录一下。比较了9i、10g、11g三个版本，在我的实验环境中（都是默认没有修改过的），9i、10g、11g的db_files默认值为200，而9i、11g的maxdatafiles为100，10g rac环境为1024，单实例为100。db_files参数在数据库的初始化参数文件中指定，maxdatafiles在控制文件中指定,一般db_files<=maxdatafiles。如果在添加一个数据文件时，其编号已经超出了maxdatafiles的设定值，但是小于或等于db_files的设定值，控制文件会自动扩展maxdatafiles的值以满足容纳更多的数据文件信息的需求，所以指定db_files参数的值对数据库更为关键和重要，因为maxdatafiles会自动扩展。
BTW:指定db_files的值会影响数据库内存的使用，详情请参考eagle的相关文章。
-The End-
故障日期：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大师的文章供参考：
-The End-
Wow，昨天在Eygle大师的Blog上看到《Oracle DBA手记》已经上架了，先恭喜一下这几位大牛（Eygle、Yangtingkun、老熊、zergduan、banping）出了新作。继续往下看，没想到第一本书是寄给我的，这里谢谢Eygle，谢谢几位大牛们，感谢Julia，因为我想大师业务缠身应该没有时间寄书：）。农历新年快到了，这本书对我来说是新年最好的礼物，同时也是莫大的鼓舞，告诫自己努力。图片作证：
-The End-
