? ORA-609就alertlog中比較常見的一個報錯，雖然并沒有太大的影響，但是頻繁的出現在alert log也是很讓人厭煩的事情，本文介紹如何排查解決ORA-609問題。

1.ORA-609官方定義

could not attach to incoming connection Cause Oracle process could not answer incoming connection Action If the situation described in the next error on the stack can be corrected, do so; otherwise contact Oracle Support

簡單的解釋就是客戶端和服務無法連接，如果排查需要看后續的跟著報錯代碼。

2.場景一：?ORA-609 + TNS-12641

??2.1首先排查alert log

一般會在alert log看到如下報錯，alert log中并無TNS相關報錯。

?2.2排查$ORACLE_HOME/network/log/sqlnet.log

可以看到大量的TNS-12641報錯????

Fatal NI connect error 12641, connecting to: (LOCAL=NO)  VERSION INFORMATION:        TNS for Linux: Version 11.2.0.4.0 - Production        Oracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production        TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production  Time: 27-APR-2024 22:14:00  Tracing not turned on.  Tns error struct:    ns main err code: 12641    TNS-12641: Authentication service failed to initialize    ns secondary err code: 0    nt main err code: 0    nt secondary err code: 0????nt?OS?err?code:?0

從報錯可以看到是和認證相關的，原因是因為在$ORACLE_HOME/network/admin/sqlnet.ora添加了

SQLNET.AUTHENTICATION_SERVICES=?(ALL)

這里涉及到一個BUG

BUG 23728771 - ABOUT AN ACTUAL BEHAVIOR SQLNET.AUTHENTICATION_SERVICES

在將 SQLNET.AUTHENTICATION_SERVICES 設置為 ALL 時，服務器會默認選擇認證適配器 KERBEROS5、RADIUS 和 KERBEROS5。如果在客戶端/服務器的 sqlnet.ora 中未指定 sqlnet.authentication_kerberos5_service，則在執行 kerberos 認證時將失敗，并出現 ORA-12641 錯誤。

2.3解決方案 ?
修改$ORACLE_HOME/network/admin/sqlnet.ora

SQLNET.AUTHENTICATION_SERVICES= (ALL) 改為SQLNET.AUTHENTICATION_SERVICES=?(NONE)

3.場景二：ORA-609 + ORA-12537

?????

3.1 排查alert log

? 一般alert log中會有?ORA-609和ORA-12537的報錯

ORA-00609: could not attach to incoming connectionORA-12537: TNS:connection closedORA-609 : opiodr aborting process unknown ospid (xxxx)

?3.2 排查$ORACLE_HOME/network/log/sqlnet.log

可以看到sqlnet.log中有TNS-12537

Fatal NI connect error 12537, connecting to:(LOCAL=NO)VERSION INFORMATION:TNS for 64-bit Windows: Version 11.1.0.7.0 - ProductionOracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.1.0.7.0 - ProductionWindows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.1.0.7.0 - ProductionTime: 12-OCT-2009 10:03:39Tracing to file: E:\app\oracle\product\11.1.0\db_1\NETWORK\trace\svr1_7464.trcTns error struct:ns main err code: 12537TNS-12537: TNS:connection closedns secondary err code: 12560nt main err code: 0nt secondary err code: 0nt OS err code: 0

3.3?listener log中會有類似如下報錯

日志顯示連接已建立，沒有明顯錯誤。這是因為在listener將連接移交給服務器進程之后，連接失敗了。

12-OCT-2009 10:03:39 * (CONNECT_DATA=(SID=ORCL)) * (ADDRESS=(PROTOCOL=tcp)(HOST=123.456.1.123)(PORT=3158)) * establish * ORCL * 012-OCT-2009 10:03:39 * (CONNECT_DATA=(SID=ORCL)) * (ADDRESS=(PROTOCOL=tcp)(HOST=123.456.1.123)(PORT=3159)) * establish * ORCL * 0

3.4 解決方案

ORA-609 錯誤是在客戶端連接在完成或在連接/身份驗證過程完成之前中斷連接過程時引發的。很多時候，這種連接中斷是由于超時引起的。從 10gR2 開始，入站連接超時的默認值已設置為 60 秒。這個時間限制通常不足以完成整個連接過程。當錯誤是間歇性的時，通常不表示存在嚴重問題。這只是意味著服務器進程在整個連接過程完成之前超時。

我們還發現，在由 DB Console 和 Enterprise Manager 代理（emagent）監視的數據庫安裝中，ORA-609 錯誤經常發生。在啟動 DB Console 并且作為例行操作后，emagent 將反復嘗試連接到目標實例。我們可以在 listener.log 中看到頻繁的 emagent 連接，而不會出現錯誤。然而，偶爾可能會在數據庫處未能完成連接過程，因此會引發 ORA-609 錯誤。emagent 將簡單地重試連接，并可能在隨后的嘗試中成功。（前提是在監聽器或數據庫上沒有發生真正的故障）。這種臨時連接失敗不會反饋給 DB Console，并且除了 ORA-609 之外，沒有其他指示表明發生了故障。

綜上引起ORA-609報錯的原因有很多，要想真正的追蹤到根本原因相對是比較難 的；但是可以有相對簡單的辦法來應對，常用的方案就是拉長連接超時的時間具體操作為修改$ORACLE_HOME/network/admin/sqlnet.ora(oracle 非grid)添加如下參數，無需重啟DB和reload監聽

SQLNET.INBOUND_CONNECT_TIMEOUT=120

3.5排查根本原因方案

??如果修改連接超時參數后還頻繁的出現ORA-609，那么就需要更詳細的排查官方建議方案如下：

A.?在客戶端的?SQLNET.ORA 文件添加如下trace參數

DIAG_ADR_ENABLED=off                  # Disable ADR if version 11gTRACE_LEVEL_CLIENT = 16               # Enable level 16 traceTRACE_TIMESTAMP_CLIENT = ON           # Set timestamp in the trace filesTRACE_DIRECTORY_CLIENT = <DIRECTORY>  # Control trace file locationTRACE_FILELEN_CLIENT =<n>     #Control size of trace set in kilobytes eg 20480TRACE_FILENO_CLIENT =<n>      #Control number of trace files per process

如果連接模型是 JDBC thin，則需要對客戶端進行 Javanet 跟蹤。請參閱文檔 793415.1 How to Perform the Equivalent of SQL*Net Client Tracing with Oracle JDBC Thin Driver.。

如果使用的是 11.2 版本的 JDBC thin 客戶端，則可以使用以下說明文檔 1050942.1?How to Trace the Network Packets Exchanged Between JDBC and the RDBMS in Release 11.2。

B.?在服務器端設置trace參數

DIAG_ADR_ENABLED=off                  # Disable ADR if version 11gTRACE_LEVEL_SERVER = 16               # Enable level 16 traceTRACE_TIMESTAMP_SERVER = ON           # Set timestamp in the trace filesTRACE_DIRECTORY_SERVER?=?<DIRECTORY>??#?Control?trace?file?locationTRACE_FILELEN_SERVER =<n>   #Control size of trace set in kilobytes eg 20480TRACE_FILENO_SERVER =<n>       #Control number of trace files per process

Cyclic tracing will allow you to control the size of and number of trace files that are produced.
The TRACE_FILELEN parameter is for the size of a trace file.
The TRACE_FILENO parameter is the number of traces per process.
?

C.?設置錯誤堆棧以捕獲失敗。 當捕獲 Oracle Net 客戶端跟蹤不可行時，這可能會特別有用.?

SQL> alter system set events '609 errorstack(3)';Once a few traces have been collected while the error is reproduced:SQL> alter system set events '609 off';

然后開SR把這些log上傳給oracle support去做進一步排查?。
?

參考文檔

NOTE:609.1?- ORA-609 TNS-12537 and TNS-12547 in 11g Alert.log?

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

Troubleshooting Guide ORA-609 : Opiodr aborting process unknown ospid (Doc ID 1121357.1)?

Alert Log Errors: ORA-609 & TNS-12641 -Authentication Service Failed To Initialize (Doc ID 2426368.1)

?