ALERT日志中常见监听相关报错之三:ORA-609 TNS-12537 and TNS-12547 or TNS-12170 TNS-12535错误的排查

1.11G中ALERT日志中有报错ORA-609 TNS-12537 and TNS-12547 or TNS-12170  12170, ‘TNS-12535等问题的解决方法:

Troubleshooting Guide for TNS-12535 or ORA-12535 or ORA-12170 Errors (文档 ID 119706.1)

TNS-12535 / ORA-12535 on Connection to Database (文档 ID 214122.1)

11g: ORA-609 TNS-12537 and TNS-12547 or TNS-12170 in 11g Alert.log (文档 ID 1116960.1)

Fatal NI Connect Error 12170, ‘TNS-12535: TNS:operation timed out‘ Reported in 11g Alert Log (文档 ID 1286376.1)

TNS-12535 or ORA-12535从本质上来说是客户端与服务器之间计时的问题。a timing issue between the client and server.

这个错误通常是由于防火墙或网络不稳定、慢引起的超时。也可能是主机的TCP QUEUESIZE setting设置问题。

通常也需要排查监听配置文件:

listener.ora -->

CONNECT_TIMEOUT_<listener_name> (8.1.x and lower only)

or

INBOUND_CONNECT_TIMEOUT_<listener_name> (9.2 and above)

sqlnet.ora -->

SQLNET.INBOUND_CONNECT_TIMEOUT (9.2 and up).

listener.ora: INBOUND_CONNECT_TIMEOUT_listenername

set to a value in seconds and determines how long a client has to provide the necessary authentication information to a database.

单位为秒,客户端需要在指定的时间内提交需要的认证信息。

sqlnet.ora: SQLNET.INBOUND_CONNECT_TIMEOUT

INBOUND_CONNECT_TIMEOUT_listenername is set to a value in seconds and determines how long a client has to complete its connect request to the listener after the network connection has been established.

单位为秒,客户端与监听建立连接后多久需要完成连接请求

例如:

Sqlnet.ora: SQLNET.INBOUND_CONNECT_TIMEOUT=180

Listener.ora: INBOUND_CONNECT_TIMEOUT_listener_name=120

参考:11g: ORA-609 TNS-12537 and TNS-12547 or TNS-12170 in 11g Alert.log (文档 ID 1116960.1)

排查方法:

1.可以PING通连接串中的主机HOST--如RAC的VIP/SCAN,检查防火墙、路由、网络慢等

2.客户端和服务器的OS平台、版本是ORACLE支持的

3.如果使用9I或之前的Oracle Names Server,配置临时tnsnames.ora 并在sqlnet.ora file 写入 NAMES.DIRECTORY_PATH = (TNSNAMES)

4.如果正在使用Shared Server,尝试使用SERVER=DEDICATED

5.数据库服务器负载高,CPU/内存等检查

6.10.1、10.2版本 客户端可能在网络慢时收到ORA-12535 or ORA-12170,修改如下:

These parameters are set on the SERVER side:

listener.ora: INBOUND_CONNECT_TIMEOUT_listenername   --为0(无限期)

sqlnet.ora: SQLNET.INBOUND_CONNECT_TIMEOUT   --120防DOS

7.11g版数据库警报日志还可能包含12535和/或12170错误的组合。

排查客户端是否异常发出过多连接、连接风暴等问题。

8.监听器负载大,大量客户端连接积压,监听器不能及时处理。--或者连接风暴

9.服务器正在启动过程中。。

10.TRACE跟踪一下 DOC:文档 ID 1116960.1

解决方法:

1.8I及之前版本,在 listener.ora中配置CONNECT_TIMEOUT_<listener_name> and make it a higher value.

2.9I及之后版本,CONNECT_TIMEOUT_<listener_name> parameter is obsoleted.

需要根据不同版本来设置。

3.11G中此错误 会出现在ALERT日志中。这个错误对应用基本没有影响,通常可以忽略。

ORACLE就给了一个损招,不让监听超时错误出现在告警日志里,回到10G的形式保存在监听的LOG中。。

Fatal NI Connect Error 12170, ‘TNS-12535: TNS:operation timed out‘ Reported in 11g Alert Log (文档 ID 1286376.1)

方法1: server‘s sqlnet.ora :

DIAG_ADR_ENABLED = OFF

方法2:

Also, to back out the ADR diag for the Listener component,  server‘s listener.ora:

DIAG_ADR_ENABLED_LISTENER = OFF

此时出现监听超时错误只出现在监听日志,注意ADR_BASE_LISTENER = /orabase   --删除此条目。

对sqlnet文件的修改是要重新注册监听才能生效的。

4.11G中还可以设置sqlnet.ora--文档 ID 1628949.1

SQLNET.EXPIRE_TIME=n  Where <n> is a non-zero value set in minutes.

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-10-14 10:32:44

ALERT日志中常见监听相关报错之三:ORA-609 TNS-12537 and TNS-12547 or TNS-12170 TNS-12535错误的排查的相关文章

ALERT日志中常见监听相关报错之一:ORA-609错误的排查

参考MOS文档有: Troubleshooting Guide ORA-609 : Opiodr aborting process unknown ospid (文档 ID 1121357.1) Alert.log shows ORA-609 with TNS-12537: TNS:connection closed (文档 ID 1538717.1) Fatal NI Connect 12560' And 'ORA-609 Opiodr Aborting Process' Errors In

ALERT日志中常见监听相关报错之二:ORA-3136错误的排查

近期在多个大型系统中遇到此问题,一般来说如果客户端未反映异常的话可以忽略的. 如果是客户端登陆时遇到ORA-12170: TNS:Connect timeout occurred,可以参考 http://blog.csdn.net/haibusuanyun/article/details/14517211#t12 ############### 参考MOS文档有: Troubleshooting Guide for TNS-12535 or ORA-12535 or ORA-12170 Erro

ALERT日志中常见监听错误:ORA-3136错误的排查

[现象] ***********************************************************************   Fatal NI connect error 12170.     VERSION INFORMATION:         TNS for Linux: Version 12.1.0.2.0 - Production         Oracle Bequeath NT Protocol Adapter for Linux: Versio

【js监听报错】页面监听js报错问题

<html> <head> <script type="text/javascript"> // 页面监听js报错问题 onerror=handleErr var txt="" function handleErr(msg,url,l) { txt="本页中存在错误如下:\n\n" txt+="错误:" + msg + "\n" txt+="URL: "

javaScript中常见的几种报错类型

一般我们运行代码的时候,在控制台报错会相应的显示你错误的行数,找到那一行,查找你相应的错误 1.xxx is not defined xxx 没有定义 2.xxx is not a function xxx 不是一个函数 xxx此时是undefined 3.Cannot read property 'xxx' of undefined 不能读取undefined的xxx属性 xxx前面的变量是undefined 4.Cannot set property 'xxx' of null 不能给nul

vue.js 中使用(...)运算符报错的解决方法

vue.js 中使用(...)运算符报错的解决方法 Syntax Error:Unexpected token(XX:X) }, computed:{ ...mapGetters([ 'pageSize' ]) }, 这个错误是在项目中,不识别es6的扩展运算符,解决办法(四步走)如下: 第一步:安装babel-plugin-transform-object-rest-spread cnpm install babel-plugin-transform-object-rest-spread 第二

oracle 11g在安装过程中出现监听程序未启动或数据库服务未注册到该监听程序

15511477451 原文 oracle 11g在安装过程中出现监听程序未启动或数据库服务未注册到该监听程序? 环境:win7 64位系统.oracle11g数据库 问题描述:在win7 64位系统下安装oracle11g,在使用Database configuration Assistant创建数据库时,在创建到85%的时候报错.错误提示内容如下. 错误分析: 经过查看警告中给出的日志文件 F:\develop\oracle_data\app\Administrator\cfgtoollog

spring中配置监听队列的MQ

一.spring中配置监听队列的MQ相关信息注:${}是读取propertites文件的常量,这里忽略.绿色部分配置在接收和发送端都要配置. <bean id="axx" class="com.ibm.mq.jms.MQQueueConnectionFactory"> <property name="hostName" value="${}" />  <property name="po

【翻译自mos文章】升级到11.2.0.4之后在alert日志中出现 NUMA 警告信息

注:与本文有关的文章为:http://blog.csdn.net/msdnchina/article/details/43763927 升级到11.2.0.4之后在alert日志中出现 NUMA 警告信息 翻译自mos文章:NUMA warning message appear after upgrade to 11.2.0.4 (文档 ID 1600824.1)1 适用于: Oracle Database - Enterprise Edition - Version 11.2.0.4 and