datastage作业hang住

最近生产上经常有ds作业hang住，杀掉进程重做后偶尔成功，偶尔不成功，报错信息如下

 main_program: (aptoci.C:500). Message: ORA-12152: TNS:unable to send break message(aptoci.C:637). Message: ORA-03114: not connected to ORACLE(aptoci.C:549). Message: ORA-03114: not connected to ORACLE(aptoci.C:606). Message: ORA-24338: statement handle not executed(aptoci.C:493). Message: ORA-03114: not connected to ORACLE(aptoci.C:637). Message: OCI_INVALID_HANDLE (aptoci.C:545). Message: OCI_INVALID_HANDLE (aptoci.C:606). Message: OCI_INVALID_HANDLE (aptoci.C:493). Message: ORA-03114: not connected to ORACLE

查询oracle错误吗 ORA-12152 ，应该是网络方面的问题，下面的文章转发其他博客的，原地址为

http://blog.sina.com.cn/s/blog_53d137da0102wqf4.html

网络设备重新更换配置，或者网络链路有变化的时候常会出点问题。今天的问题记载一下，以防不时之需。  新的数据中心核心的ORACLE RAC服务器刚刚顺利安装完毕，应用组安装测试数据库进行测试，刚刚开始就碰到这个问题：应用组的同事，使用pl/sql developer  v7.15 查一个表 select * from   ALL_xxx;数据查不出来，报出一个错误：ORA-12152: TNS:unable to send break message 从错误内容看到关键字TNS，此类问题，大部分和网络相关，基本上和数据库服务进程关系不大，因此不要去花时间研究database server1 . 换工具用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 1215212152, 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 1215112151, 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 1257112571, 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.

datastage作业hang住相关推荐

HANA 数据库备份hang住的解决办法
今天遇到 HANA 数据库备份hang住的情况.经过查 SAP NOTE 解决,记录一下过程.两个NOTE如下: 2452735 - HANA Backup failing with "[4 ...
oracle删除表不等待,oracle故障处理之删除大表空间hang住
背景数据库分区表数据越来越大,需要对过期话的数据进行迁移,以及大的分区表需要进行数据的清理和删除,达到释放磁盘空间的目的. 问题说明环境:linux 6.X 数据库:oracle 11.2.0.4 ...
c++排查线程hang住_Kafka学习笔记之kafka高版本Client连接0.9Server引发的血案排查 - 时光飞逝，逝者如斯...
0x00 概述 kafka server虽然原则上是兼容详细的client,但只是高版本的Server端兼容低版本的Client端: 在有高版本Client端连接时,会导致低版本Server集群会ha ...
OGG目标端复制Sequence时Hang住的问题
昨天遇到一个问题一个OGG的复制进程在复制序列(Sequence)时Hang住不动,进程状态一直是Running状态但是不往前进行复制,导致进程延迟6个多小时 GGSCI (ctm-3) 2> ...
mysql 备库 hang住_mysql主键的缺少导致备库hang住
最近线上频繁的出现slave延时的情况,经排查发现为用户在删除数据的时候,由于表主键的主键的缺少,同时删除条件没有索引,或或者删除的条件过滤性极差,导致slave出现hang住,严重的影响了生产环境的 ...
mysql客户端hang_MySQL所有操作hang住了，怎么破？
<MySQL所有操作hang住了,怎么破?>要点: 本文介绍了MySQL所有操作hang住了,怎么破?,希望对您有用.如果有疑问,可以联系我们. 作者介绍王松磊,现任职于UCloud,从 ...
plsql一直正在编译_使用plsql/devlop编译过程hang住案列小结
今天有位同事在使用plsql/devleop编译存储过程时老是导致整个操作界面hang住长时间无法响应,以下是我的处理过程,简要记录之. 1.查询v$session视图确定hang住的会话相关信息,比 ...
oracle数据库延迟执行,如何诊断oracle数据库运行缓慢或hang住的问题
为了诊断oracle运行缓慢的问题首先要决定收集哪些诊断信息,可以采取下面的诊断方法: 1.数据库运行缓慢这个问题是常见还是在特定时间出现如果数据库运行缓慢是一个常见的问题那么可以在问题出现的时候收 ...
oracle关闭rs,Oracle 关闭(shutdown immediate)时hang住
昨天晚上生产的两套10.2.0.4的数据库修改了参数,需要重启.在发出shutdown immediate命令后等了大概10分钟的时间,数据库还没有down下来.检查后台alert日志,发现从开始sh ...

datastage作业hang住

datastage作业hang住相关推荐

最新文章

热门文章