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 The Alert Log (文档 ID 987162.1)
数据库的ALERT日志中常会见到ORA-609、ORA-3136/ORA-609 TNS-12537 and TNS-12547 or TNS-12170  12170, 'TNS-12535等相关错误,对此类型问题进行整理归纳,如下:
1.ORA-609错误的排查指南:
Alert log 可以看到如下错误信息:
    Fatal NI connect error 12537, connecting to:
     (LOCAL=NO)
    
      VERSION INFORMATION:
        TNS for Linux: Version 11.2.0.3.0 - Production
        Oracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.3.0 - Production
        TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.3.0 - Production
      Time: 26-FEB-2013 02:23:51
      Tracing not turned on.
      Tns error struct:
        ns main err code: 12537
    
    TNS-12537: TNS:connection closed
        ns secondary err code: 12560
        nt main err code: 0
        nt secondary err code: 0
        nt OS err code: 0
    opiodr aborting process unknown ospid (28725) as a result of ORA-609
    
    First an explanation of this kind of errors.

The message
    opiodr aborting process unknown ospid (.....) as a result of ORA-609
is just a notifications that oracle database closed (aborted) a dedicated process because of 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与客户端通信时发现客户端关闭了。

###############################
使用跟踪来排查:
文档:Troubleshooting Guide ORA-609 : Opiodr aborting process unknown ospid (文档 ID 1121357.1)
对于这种问题的排查,使用listener.log或者SQLNET的跟踪效果不太好,因为每秒可能有很多连接同时SQLNET的跟踪未提供更多的客户端信息。
此时可以尝试使用OS层面的跟踪。
如:1111为监听进程,ps -ef|grep tnslsnr   查出
LINUX: strace -rf -o /tmp/lsnr1.log -p 1111
HP-UX: tusc -T hires -afpo /tmp/lsnr1.log 1111


如果使用TRACE跟踪,如下:
3. Oracle Net Level 16 Server tracing. Add to server side SQLNET.ORA file
DIAG_ADR_ENABLED=off                  # Disable ADR if version 11g
TRACE_LEVEL_SERVER = 16               # Enable level 16 trace
TRACE_TIMESTAMP_SERVER = ON           # Set timestamp in the trace files
TRACE_DIRECTORY_SERVER = <DIRECTORY>  # Control trace file location

TRACE_FILELEN_SERVER =<n>   #Control size of trace set in kilobytes eg 20480
TRACE_FILENO_SERVER =<n>       #Control number of trace files per process

使用Errorstack方法如下:
4. Errorstack: Setup errorstack to capture failure. This can be particular useful when capturing an Oracle Net client trace is not feasible.
SQL> alter session set events '609 errorstack(3)';

Once a few traces have been collected while the error is reproduced:
SQL> alter session set events '609 off';
###############################################


关于此问题的解决方法有:
文档:Alert.log shows ORA-609 with TNS-12537: TNS:connection closed (文档 ID 1538717.1)
可能原因:
客户端卡住、崩溃;连接被防火墙KILL;客户端超时设置;客户端连接后立刻关闭;网络不稳定;
需要检查客户端tnsnames.ora/sqlnet.ora中信息:

    possible timeouts in sqlnet.ora in client oracle home:

    sqlnet.outbound_connect_time
    sqlnet.recv_timeout
    sqlnet.send_timeout
    tcp_connect_timeout
    
   possible timeout in client connect descriptor (hardcoded in client application or in client tnsnames.ora):
    connect_timeout
    
--------------

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
这个错误通常是由于在 SQL 查询语句使用了非法的变量名或编号而引起的。这可能是因为你在查询语句使用了不支持的变量名或编号,或者是因为你在使用变量时出现了语法错误。 你可以通过以下几个步骤来解决这个问题: 1. 检查 SQL 查询语句的变量名或编号是否正确。确保变量名或编号与表的列名匹配,并且没有拼写错误或语法错误。尝试使用简单的查询语句,例如 `SELECT * FROM your_table`,以确保查询语句没有错误。 2. 检查你的代码是否正确地绑定了变量。确保你在绑定变量时使用了正确的语法,并且变量在查询语句被正确地引用。你可以尝试使用 `print` 语句来调试代码,查看绑定变量的值是否正确。 3. 如果你仍然无法解决问题,可以尝试将查询语句分解为多个步骤,并使用 `print` 语句来检查每个步骤的结果。这将帮助你确定哪个步骤出现了问题。 下面是一个示例代码,可以帮助你检查代码错误: ```python import cx_Oracle # 建立 Oracle 数据库连接 conn = cx_Oracle.connect('username/password@host:port/service_name') # 定义查询语句和变量 query = "SELECT * FROM your_table WHERE column1 = :value1 AND column2 = :value2" value1 = 'some_value' value2 = 'other_value' # 执行查询语句 cursor = conn.cursor() cursor.execute(query, {'value1': value1, 'value2': value2}) result = cursor.fetchall() # 打印结果 print(result) # 关闭数据库连接 cursor.close() conn.close() ``` 在上面的代码,你需要将用户名、密码、主机、端口和服务名替换为你的 Oracle 数据库的实际值。你还需要将查询语句、变量名和表名替换为你的实际值。 如果你仍然遇到问题,请提供具体的错误消息和代码,以便我更好地帮助你解决问题。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值