|
网络设备重新更换配置，或者网络链路有变化的时候常会出点问题。今天的问题记载一下，以防不时之需。 新的数据中心核心的ORACLE RAC服务器刚刚顺利安装完毕，应用组安装测试数据库进行测试，刚刚开始就碰到这个问题： 应用组的同事，使用pl/sql developer v7.15 查一个表 select * from ALL_xxx; 数据查不出来，报出一个错误： ORA-12152: TNS:unable to send break message 从错误内容看到关键字TNS，此类问题，大部分和网络相关，基本上和数据库服务进程关系不大，因此不要去花时间研究database server 1 . 换工具用sqlplus测试，发现没有任何问题，可以正常显示所有数据（没法解释，难道sqlplus打包的方式不一样？不愧是经典工具，也许是高手开发的，比较聪明，能适应各种恶劣环境。） 2. 变换SQL语句，发现数据少的时候不会出问题，到一定的行数的时候出问题，本次 19行以内没有问题，超过则有问题， 顺着这个思路，为什么记录少可以，只能说明oracle此时发的包足够的小，小到Oracle数据库包发出后，os和网络设备不需要进行拆包。要测试现有的网络环境，最大可以发送多大的包，有个办法比较笨的办法直接不停的ping -f ，多测几次就可以测出 C:\Users\andzen>ping -f -l 1280 172.16.133.2 正在 Ping 172.16.133.2 具有 1280 字节的数据: 需要拆分数据包但是设置 DF。 需要拆分数据包但是设置 DF。 需要拆分数据包但是设置 DF。 需要拆分数据包但是设置 DF。 172.16.133.2 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 0，丢失 = 4 (100% 丢失)，
C:\Users\andzen>ping -f -l 1278 172.16.133.2 正在 Ping 172.16.133.2 具有 1278 字节的数据: 需要拆分数据包但是设置 DF。 需要拆分数据包但是设置 DF。 需要拆分数据包但是设置 DF。 需要拆分数据包但是设置 DF。 172.16.133.2 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 0，丢失 = 4 (100% 丢失)，
C:\Users\andzen>ping -f -l 1273 172.16.133.2 正在 Ping 172.16.133.2 具有 1273 字节的数据: 需要拆分数据包但是设置 DF。 需要拆分数据包但是设置 DF。 172.16.133.2 的 Ping 统计信息: 数据包: 已发送 = 2，已接收 = 0，丢失 = 2 (100% 丢失)，
C:\Users\andzen>ping -f -l 1272 172.16.133.2 正在 Ping 172.16.133.2 具有 1272 字节的数据: 来自 172.16.133.2 的回复: 字节=1272 时间=1ms TTL=252 来自 172.16.133.2 的回复: 字节=1272 时间=1ms TTL=252 来自 172.16.133.2 的回复: 字节=1272 时间=1ms TTL=252 来自 172.16.133.2 的回复: 字节=1272 时间=1ms TTL=252 172.16.133.2 的 Ping 统计信息: 数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)， 往返行程的估计时间(以毫秒为单位): 最短 = 1ms，最长 = 1ms，平均 = 1ms
C:\Users\andzen>ping -f -l 1271 172.16.133.2
正在 Ping 172.16.133.2 具有 1271 字节的数据: 来自 172.16.133.2 的回复: 字节=1271 时间=1ms TTL=252 来自 172.16.133.2 的回复: 字节=1271 时间=1ms TTL=252 来自 172.16.133.2 的回复: 字节=1271 时间=1ms TTL=252 172.16.133.2 的 Ping 统计信息: 从以上一步一步尝试可以得知，小于1272字节的包是可以不需要拆分的通过网络，到达数据库服务器的，说明网络环境的异常，使的系统最大能发生不超过1272byte的包。
如果不想彻底解决问题，此时有比较简单的办法解决问题。 在所有访问oracle数据库的客户端tnsname.ora 或者其他连接字符串（如JDBC）里面： 配置SDU参数等于1272。 为了证实这个想法： 1). 修改TNSNAME.ORA文件，在里面增加(SDU=1272) 2).重新启动pl\sql developer v7.15 3).重新执行上面的select语句，果然正常了 这种办法适合作为临时解决问题的办法，只是规避了问题而已，如果有几百个个客户端配置，工作量也不少，做为一个负责任的DBA，应该找到异常的根源。
3. 看看是不是网络MTU设置问题，如果多个网络设备mtu不一致，经常会导致大包不能正常传送，基本上否定MTU不匹配导致，因为10000字节的包都可以通过(会自动分拆包) ping -l 10000 172.16.133.2 来自 172.16.133.2 的回复: 字节=10000 时间=2ms TTL=252 来自 172.16.133.2 的回复: 字节=10000 时间=2ms TTL=252 来自 172.16.133.2 的回复: 字节=10000 时间=2ms TTL=252 基本没有问题 4. 换测试程序，用exp程序 Export: Release 10.1.0.4.0 - Production on Thu Jun 4 14:52:46 2009 Copyright (c) 1982, 2004, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.1.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters and Data Mining options Export done in ZHS16GBK character set and UTF8 NCHAR character set server uses UTF8 character set (possible charset conversion) . exporting pre-schema procedural objects and actions 。。。。。。 . exporting cluster definitions . about to export SC_OWNER's tables via Conventional Path ... . . exporting table ADMIN_PRIVILEGES 2 rows exported EXP-00091: Exporting questionable statistics. EXP-00091: Exporting questionable statistics. . . exporting table ALL_SOURCES EXP-00056: ORACLE error 12152 encountered ORA-12152: TNS:unable to send break message EXP-00008: ORACLE error 1023 encountered ORA-01023: Cursor context not found (Invalid cursor number) EXP-00000: Export terminated unsuccessfully 问题依旧，2行的表可以成功，下面的表 ALL_xxx （820行）就不行了，说明还是和数据量多少和包有关系 4. 换测试客户端，把语句换到RAC服务器上测试 . . exporting table USER_SESSION_BK 311687 rows exported . . exporting table USER_SESSION_MENU_BK 0 rows exported . . exporting table WORKSTATION 74 rows exported . . exporting table XMI_ASYNC_MSG_JRNL_BK 8069 rows exported . . exporting table TOAD_PLAN_SQL 0 rows exported . . exporting table TOAD_PLAN_TABLE 84196 rows exported . exporting synonyms . .......................... . exporting materialized views . exporting snapshot logs . exporting job queues . exporting refresh groups and children . exporting dimensions . exporting post-schema procedural objects and actions . exporting statistics Export terminated successfully without warnings. 没有问题，311687 条的表都可以exp出来，反面证明： 数据库server进程没有问题；
问题还在于跨网段的设备或防火墙； 问题定位之后，下面的工作需要网络工程师一起合作完成： 1. 把防火墙上，针对某几个客户端，打开旁路，等于防火墙让这些客户端访问的数据直接通过，不检查了， 在测试exp，果然正常了，基本确定问题在防火墙上； 2. 然后网络工程师关闭旁路，继续测试，巧的是，此时exp也仍然正常，大家都很奇怪。 3.然后居然发现所有有问题的客户端都正常了，包含之前没有开旁路的 4. 反过来想一想为什么呢，网络工程师说，刚刚在开通旁路的时候，同时升级了防火墙软件版本，原来的低版本软件没有旁路功能，这样就好理解了，防火的原来的软件有缺陷（bug），于是把所有同类的防火墙都更新软件，事后网络工程师说我们的防火墙很便宜，才几万块，看来，便宜真的没有多少好货。 错误信息参考： p1:oracle>oerr ORA 12152 12152, 00000, "TNS:unable to send break message" // *Cause: Unable to send break message. Connection probably disconnected. // *Action: Reestablish connection. If the error is persistent, turn // on tracing and reexecute the operation.
p1:oracle>oerr ora 12151 12151, 00000, "TNS:received bad packet type from network layer" // *Cause: Internal error. // *Action: Not normally visible to the user. For further details, turn // on tracing and reexecute the operation. If error persists, contact // Worldwide Customer Support.
p1:oracle>oerr ora 12571 12571, 00000, "TNS:packet writer failure" // *Cause: An error occurred during a data send. // *Action: Not normally visible to the user. For further details, turn // on tracing and reexecute the operation. If error persists, contact // Oracle Customer Support. |
|
|
