监听相关报错:TNS-12535: TNS:operation timed out、TNS-00505: Operation timed out、ORA-609

2023-10-30 16:59

本文主要是介绍监听相关报错:TNS-12535: TNS:operation timed out、TNS-00505: Operation timed out、ORA-609,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

1 问题

数据库在巡检的时候发现alert日志里出现监听相关的报错

  • rac1
Tue Sep 03 10:19:48 2019***********************************************************************Fatal NI connect error 12170.VERSION INFORMATION:TNS for Linux: Version 11.2.0.4.0 - ProductionOracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.4.0 - ProductionTCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - ProductionTime: 03-SEP-2019 10:19:48Tracing not turned on.Tns error struct:ns main err code: 12535TNS-12535: TNS:operation timed outns secondary err code: 12560nt main err code: 505TNS-00505: Operation timed outnt secondary err code: 110nt OS err code: 0Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.201.111)(PORT=49310))
  • rac2
Tue Sep 03 16:47:06 2019***********************************************************************Fatal NI connect error 12547, connecting to:
(LOCAL=NO)VERSION INFORMATION:TNS for Linux: Version 11.2.0.4.0 - ProductionOracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.4.0 - ProductionTCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - ProductionTime: 03-SEP-2019 16:47:06Tracing not turned on.Tns error struct:ns main err code: 12547TNS-12547: TNS:lost contactns secondary err code: 12560nt main err code: 0nt secondary err code: 0nt OS err code: 0
opiodr aborting process unknown ospid (175308) as a result of ORA-609

数据库的ALERT日志中常会见到ORA-609ORA-3136/ORA-609TNS-12537 and TNS-12547 or TNS-12170TNS-12535等相关错误

2 原因排查与解决

2.1 RAC1的TNS-12535TNS-00505 错误原因

参考官方说明关于该警告的说明:

   Note:465043.1The "WARING:inbound connection timed out (ORA-3136)" in the alert log indicates that the client was not able to complete it's authentication within the period of time specified by parameter SQLNET.INBOUND_CONNECT_TIMEOUT.You may also witness ORA-12170 without timeout error on the database sqlnet.log file.This entry would also have the client address which failed to get authenticated.Some applications or JDBC thin driver applications may not have these details.

可能的原因:

  • 网络攻击,例如:半开连接攻击
    Server gets a connection request from a malcious client which is not supposed to connect to the database,in which case the error thrown is the correct behavior.You can get the client address for which the error was thrown via sqlnet log file.
  • Client在default 60秒内没有完成认证
    The server receives a valid client connection request but the client tabkes a long time to authenticate more than the default 60 seconds.
  • DB负载太高
    The DB server is heavily loaded due to which it cannot finish the client logon within the timeout specified.
    WANGING:inbound connection timed out (ORA-3136)

2.2 解决办法

1.查找问题时间段的alert日志和监听日志,其位置分别是$ORACLE__BASE/diag/rdbms/db_name/$ORACLE_SID/trace/$ORACLE__BASE/diag/tnslsnr/hostname/listener/trace/

2.如果alert日志显示如上报错,但listener日志显示正常,那么说明确实是数据库以外的问题,监听正常,就是网络方面的原因了。可能就是client暂时没有连接。
除非大批量客户端或所有的客户端都连不上,才用排查监听、网络或防火墙权限等问题。
出现这个报错,是会两个节点上都有的。

3.如果监听日志显示了其他报错,那么再根据报错找到相应的解决办法。

  • 这跟监听的一个参数有关:SQLNET.INBOUND_CONNECT_TIMEOUT
    这个参数从9i开始引入,指定了客户端连接服务器并且提供认证信息的超时时间,如果超过这个时间客户端没有提供正确的认证信息,服务器会自动中止连接请求,同时会记录试图连接的IP地址和ORA-12170:TNS:Connect timeout occurred错误。
    这个参数的引入,主要是防止DoS攻击,恶意攻击者可以通过不停的开启大量连接请求,占用服务器的连接资源,使得服务器无法提供有效服务。在10.2.0.1起,该参数默认设置为60秒。
    但是,这个参数的引入也导致了一些相关的Bug。比如:
    Bug 5594769 - REMOTE SESSION DROPPED WHEN LOCAL SESSION SHARED AND INBOUND_CONNECT_TIMEOUT SET
    Bug 5249163 - CONNECTS REFUSED BY TNSLSNR EVERY 49 DAYS FOR INBOUND_CONNEC_TIMEOUT SECONDS
    
    该参数可以通过设置为0来禁用,在服务端:
    1)、设置sqlnet.ora文件:SQLNET.INBOUND_CONNECT_TIMEOUT=0;
    2)、设置listener.ora文件:INBOUND_CONNECT_TIMEOUT_listenername=0;
    3)、然后reload或者重启监听。
    说明:这是由于连接超时所产生的问题,在10.2.0.1.0版本中sqlnet.inbound_connect_timeout参数默认为60秒,即如果连接时间超过60秒则提示超时,而在其他版本中这两个参数默认为0,即无限制。
  • 在这里插入图片描述

2.3 RAC2的ORA-609错误原因

参考官方说明关于该警告的说明:

ORA-609 means  "could not attach to incoming connection" so the database process was 'aborted' (closed) because it couldn't attach to the incoming connection passed to it by the listener.
The reason for this is found in the sqlnet error stack, in our case is:TNS-12537: TNS:connection closed.
Basically the dedicated process didn't have a client connection anymore to work with.

此报错类似通知:ORACLE因为ORA-609关闭或者叫中止了一个到数据库的专有连接–ospid (28725)。
ORA-609错误原因是:无法与进入的连接进行联系,所以无法将此连接转入监听器,所以数据库的process中止此进程。
此时报错TNS-12537: TNS:connection closed,根本原因为客户端连接不正常。

客户端通过监听器连接ORACLE数据库的过程:

  1. Client initiates a connection to the database so it connects to the listener
  2. Listener starts (fork) a dedicated database process that will receive this connection (session)
  3. After this dedicated process is started, the listener passes the connection from the client to this process
  4. The server process takes the connection from the listener to continue the handshake with the client
  5. Server process and client exchange information required for establishing a session (ASO, Two Task Common, User logon)
  6. Session is opened
    简单说就是:
    1.客户端连接到监听器
    2.监听派生fork一个子进程,交转化为专有服务器进程dedicated database process
    3.第2步完成后,监听将客户端的连接转入此专有进程dedicated process
    4.服务器进程收到从监听来的连接信息后,需要继续与客户端的连接进行handshake
    5.服务器进程与客户端进程交换建立会话需要的信息,如用户名、密码等
    6.以上OK后,SESSION OPEN。

出现这个问题时,就是在介于3、4步时客户端连接关闭,dedicated database process与客户端通信时发现客户端关闭了。

生产环境遇上这个报错一般是ISIS那边发新版本,数据库监听状态正常,巡检工具能正常询价,能连上就没事
他们有时候发版本,会把web之类的重启,就会出现这种报错

如果在月报体现,就是“就说明该报错由ISIS发布版本导致的就行”(这种记录看心情)

监听正常,就是网络方面原因了
网上的解决办法就是可以不记录追踪信息,所以记录着忽略就行
除非大批量客户端或所有的客户端都连不上,才用排查监听、网络或防火墙权限等问题
出现这个报错,是会两个节点上都有的

这篇关于监听相关报错:TNS-12535: TNS:operation timed out、TNS-00505: Operation timed out、ORA-609的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/309346

相关文章

sqlite3 相关知识

WAL 模式 VS 回滚模式 特性WAL 模式回滚模式(Rollback Journal)定义使用写前日志来记录变更。使用回滚日志来记录事务的所有修改。特点更高的并发性和性能;支持多读者和单写者。支持安全的事务回滚,但并发性较低。性能写入性能更好,尤其是读多写少的场景。写操作会造成较大的性能开销,尤其是在事务开始时。写入流程数据首先写入 WAL 文件,然后才从 WAL 刷新到主数据库。数据在开始

两个月冲刺软考——访问位与修改位的题型(淘汰哪一页);内聚的类型;关于码制的知识点;地址映射的相关内容

1.访问位与修改位的题型(淘汰哪一页) 访问位:为1时表示在内存期间被访问过,为0时表示未被访问;修改位:为1时表示该页面自从被装入内存后被修改过,为0时表示未修改过。 置换页面时,最先置换访问位和修改位为00的,其次是01(没被访问但被修改过)的,之后是10(被访问了但没被修改过),最后是11。 2.内聚的类型 功能内聚:完成一个单一功能,各个部分协同工作,缺一不可。 顺序内聚:

log4j2相关配置说明以及${sys:catalina.home}应用

${sys:catalina.home} 等价于 System.getProperty("catalina.home") 就是Tomcat的根目录:  C:\apache-tomcat-7.0.77 <PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss} [%t] %-5p %c{1}:%L - %msg%n" /> 2017-08-10

Node Linux相关安装

下载经编译好的文件cd /optwget https://nodejs.org/dist/v10.15.3/node-v10.15.3-linux-x64.tar.gztar -xvf node-v10.15.3-linux-x64.tar.gzln -s /opt/node-v10.15.3-linux-x64/bin/npm /usr/local/bin/ln -s /opt/nod

git ssh key相关

step1、进入.ssh文件夹   (windows下 下载git客户端)   cd ~/.ssh(windows mkdir ~/.ssh) step2、配置name和email git config --global user.name "你的名称"git config --global user.email "你的邮箱" step3、生成key ssh-keygen

zookeeper相关面试题

zk的数据同步原理?zk的集群会出现脑裂的问题吗?zk的watch机制实现原理?zk是如何保证一致性的?zk的快速选举leader原理?zk的典型应用场景zk中一个客户端修改了数据之后,其他客户端能够马上获取到最新的数据吗?zk对事物的支持? 1. zk的数据同步原理? zk的数据同步过程中,通过以下三个参数来选择对应的数据同步方式 peerLastZxid:Learner服务器(Follo

Jenkins 插件 地址证书报错问题解决思路

问题提示摘要: SunCertPathBuilderException: unable to find valid certification path to requested target...... 网上很多的解决方式是更新站点的地址,我这里修改了一个日本的地址(清华镜像也好),其实发现是解决不了上述的报错问题的,其实,最终拉去插件的时候,会提示证书的问题,几经周折找到了其中一遍博文

rtmp流媒体编程相关整理2013(crtmpserver,rtmpdump,x264,faac)

转自:http://blog.163.com/zhujiatc@126/blog/static/1834638201392335213119/ 相关资料在线版(不定时更新,其实也不会很多,也许一两个月也不会改) http://www.zhujiatc.esy.es/crtmpserver/index.htm 去年在这进行rtmp相关整理,其实内容早有了,只是整理一下看着方

枚举相关知识点

1.是用户定义的数据类型,为一组相关的常量赋予有意义的名字。 2.enum常量本身带有类型信息,即Weekday.SUN类型是Weekday,编译器会自动检查出类型错误,在编译期间可检查错误。 3.enum定义的枚举类有什么特点。         a.定义的enum类型总是继承自java.lang.Enum,且不能被继承,因为enum被编译器编译为final修饰的类。         b.只能定义

【Python报错已解决】AttributeError: ‘list‘ object has no attribute ‘text‘

🎬 鸽芷咕:个人主页  🔥 个人专栏: 《C++干货基地》《粉丝福利》 ⛺️生活的理想,就是为了理想的生活! 文章目录 前言一、问题描述1.1 报错示例1.2 报错分析1.3 解决思路 二、解决方法2.1 方法一:检查属性名2.2 步骤二:访问列表元素的属性 三、其他解决方法四、总结 前言 在Python编程中,属性错误(At