网络设备重新更换配置，或者网络链路有变化的时候常会出点问题。今天的问题记载一下，以防不时之需。 新的数据中心核心的ORACLERAC服务器刚刚顺利安装完毕，应用组安装测试数据库进行测试，刚刚开始就碰到这个问题：
应用组的同事，使用pl/sql developer v7.15查一个表
select * from ALL_xxx;
数据查不出来，报出一个错误：
ORA-12152: TNS:unable to send breakmessage
从错误内容看到关键字TNS，此类问题，大部分和网络相关，基本上和数据库服务进程关系不大，因此不要去花时间研究databaseserver
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 时间=1msTTL=252
来自 172.16.133.2 的回复: 字节=1272 时间=1msTTL=252
来自 172.16.133.2 的回复: 字节=1272 时间=1msTTL=252
来自 172.16.133.2 的回复: 字节=1272 时间=1msTTL=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 时间=1msTTL=252
来自 172.16.133.2 的回复: 字节=1271 时间=1msTTL=252
来自 172.16.133.2 的回复: 字节=1271 时间=1msTTL=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: Release10.1.0.4.0 - Production on Thu Jun 4 14:52:46 2009
Copyright (c) 1982,2004, Oracle. All rights reserved.
Connected to: OracleDatabase 10g Enterprise Edition Release 10.1.0.4.0 - 64bitProduction
With thePartitioning, Real Application Clusters and Data Miningoptions
Export done inZHS16GBK character set and UTF8 NCHAR character set
server uses UTF8character set (possible charset conversion)
. exportingpre-schema procedural objects and actions
。。。。。。
.exporting cluster definitions
. about to exportSC_OWNER's tables via Conventional Path ...
. . exporting table ADMIN_PRIVILEGES 2 rows exported
EXP-00091: Exportingquestionable statistics.
EXP-00091: Exportingquestionable statistics.
. . exporting table ALL_SOURCES
EXP-00056: ORACLEerror 12152 encountered
ORA-12152: TNS:unable to send breakmessage
EXP-00008: ORACLEerror 1023 encountered
ORA-01023: Cursorcontext not found (Invalid cursor number)
EXP-00000: Exportterminated unsuccessfully
问题依旧，2行的表可以成功，下面的表ALL_xxx （820行）就不行了，说明还是和数据量多少和包有关系
4. 换测试客户端，把语句换到RAC服务器上测试
. . exporting table USER_SESSION_BK 311687 rowsexported
. . 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 rowsexported
. exportingsynonyms
...........................
. exportingmaterialized views
. exporting snapshotlogs
. exporting jobqueues
. exporting refreshgroups and children
. exportingdimensions
. exportingpost-schema procedural objects and actions
. exportingstatistics
Export terminatedsuccessfully without warnings.
没有问题，311687条的表都可以exp出来，反面证明：
数据库server进程没有问题；
问题还在于跨网段的设备或防火墙；
问题定位之后，下面的工作需要网络工程师一起合作完成：
1.把防火墙上，针对某几个客户端，打开旁路，等于防火墙让这些客户端访问的数据直接通过，不检查了，
在测试exp，果然正常了，基本确定问题在防火墙上；
2. 然后网络工程师关闭旁路，继续测试，巧的是，此时exp也仍然正常，大家都很奇怪。
3.然后居然发现所有有问题的客户端都正常了，包含之前没有开旁路的
4.反过来想一想为什么呢，网络工程师说，刚刚在开通旁路的时候，同时升级了防火墙软件版本，原来的低版本软件没有旁路功能，这样就好理解了，防火的原来的软件有缺陷（bug），于是把所有同类的防火墙都更新软件，事后网络工程师说我们的防火墙很便宜，才几万块，看来，便宜真的没有多少好货。
错误信息参考：
p1:oracle>oerr ORA 12152
12152, 00000, "TNS:unable to send breakmessage"
// *Cause: Unable to send break message.Connection probably disconnected.
// *Action: Reestablish connection. If the error ispersistent, turn
// on tracing and reexecute theoperation.
p1:oracle>oerr ora 12151
12151, 00000, "TNS:received bad packet type from networklayer"
// *Cause: Internal error.
// *Action: Not normally visible to the user. For furtherdetails, turn
// on tracing and reexecute the operation. If errorpersists, contact
// Worldwide CustomerSupport.
p1:oracle>oerr ora 12571
12571, 00000, "TNS:packet writer failure"
// *Cause: An error occurred during a datasend.
// *Action: Not normally visible to the user. For furtherdetails, turn
// on tracing and reexecute the operation. If errorpersists, contact
// Oracle Customer Support.
联系客服
