ORA-12537 dblink

点击(此处)折叠或打开

1. 在检查dblink采集结果时发现，有一个库的dblink没有查询到结果(LINK_106_132_TO_PMSDB132_TAB_COMPRESS)，经实际检查，发现该dblink在使用时发生ORA-12537错误
2. dblink名称：
3. 
   
4. LINK_106_132_TO_PMSDB132_TAB_COMPRESS
5. LINK_106_159_TO_OBIDB3_TAB_COMPRESS
6. LINK_106_159_TO_PMSDB_TAB_COMPRESS
7. 
   
8. 下面是分析思路
   
9. 检查数据库监听状态
   
10. LSNRCTL> status
    
11. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=zj25k2)(PORT=1521)))
    
12. STATUS of the LISTENER
    
13. ------------------------
    
14. Alias LISTENER
    
15. Version TNSLSNR for Solaris: Version 11.2.0.4.0 - Production
    
16. Start Date 10-AUG-2016 17:06:57
    
17. Uptime 4 days 18 hr. 22 min. 53 sec
18. Trace Level off
    
19. Security ON: Local OS Authentication
    
20. SNMP OFF
    
21. Listener Parameter File /opt/oracle/product/network/admin/listener.ora
    
22. Listener Log File /opt/oracle/diag/tnslsnr/zj25k2/listener/alert/log.xml
    
23. Listening Endpoints Summary...
    
24.   (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=zj25k2)(PORT=1521)))
    
25. Services Summary...
    
26. Service "pmsdb132" has 1 instance(s).
    
27.   Instance "pmsdb132", status READY, has 1 handler(s) for this service...
    
28. Service "pmsdb132XDB" has 1 instance(s).
    
29.   Instance "pmsdb132", status READY, has 1 handler(s) for this service...
    
30. The command completed successfully
31. 从这里看监听的最近一次启动时间是8月10日17:06与dblink采集日志中，8月10日05点执行正常，以后均为执行的情况复合，初步怀疑与监听重启又关联

dblink采集日志：
SELECT_TIME
-------------------
2016-08-15 05:00:02
2016-08-15 05:00:02
2016-08-14 05:00:01
2016-08-14 05:00:01
2016-08-13 05:00:02
2016-08-13 05:00:02
2016-08-12 05:00:02
2016-08-12 05:00:02
2016-08-10 05:00:03
2016-08-10 05:00:03
2016-08-10 05:00:02
2016-08-10 05:00:02
2016-08-10 05:00:02
2016-08-10 05:00:01

接着检查监听文件以及 sqlnet . ora文件是否发生过修改

点击(此处)折叠或打开

1. rw-r--r-- 1  oracle dba 77 Jan 12 2015 listener.ora
   
2. -rw-r--r-- 1 oracle dba 530 Jan 8 2015 listener.ora_bak
   
3. drwxr-xr-x 2 oracle dba 512 Dec 29 2014 samples
   
4. -rw-r--r-- 1 oracle dba 381 Dec 17 2012 shrept.lst
   
5. -rw-r--r-- 1 oracle dba 859 Aug 10 18:06 sqlnet.ora
   
6. -rw-r--r-- 1 oracle dba 257 May 31 16:26 sqlnet.ora.20160531
   
7. -rw-r--r-- 1 oracle dba 258 Aug 10 16:56 sqlnet.ora20160810
   
8. -rw-r--r-- 1 oracle dba 273 Jun 24 2015 sqlnet.ora_0627
   
9. -rw-r--r-- 1 oracle dba 3900 Oct 5 2015 tnsnames.ora

监听文件时间比较久，说明为修改， sqlnet . ora文件的最近修改日期是Aug 10 18:06，说明在监听启动后，该文件又发生了变化。检查sqlnet.ora文件中内容

点击(此处)折叠或打开

1. #for an quan jia gu
   
2. tcp.validnode_checking = yes
   
3. tcp.invited_nodes =(10.212.211.4,10.211.106.120,10.211.106.121,10.211.106.132,10.211.106.136,********)
4. SQLNET.EXPIRE_TIME = 10
   
5. LOCAL_OS_AUTHENTICATION_LISTENER = OFF
   
6. PASSWORDS_LISTENER = ******
   
7. #sqlnet.encryption_server = rejected
   
8. #sqlnet.encryption_server = requested

经检查sqlnet.ora文件发现，增加了新的信任IP，该部分经过询问业务侧，确定业务侧在该时间点进行信任IP的增加工作，并在监听重启后，又修改该文件后，未reload监听。

经过以上分析，最终定位问题为，新增信任IP后，未reload lsnrctl 导致，最终reload监听后，恢复正常。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28551528/viewspace-2123488/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/28551528/viewspace-2123488/