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
--------------
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
--------------
相關文章
- 排查錯誤日誌
- 常見的錯誤日誌型別型別
- Git相關 | Git 常見的錯誤Git
- Mysql5.7 的錯誤日誌中最常見的note日誌MySql
- 案例二十每分鐘監控錯誤日誌併傳送郵件給相關人員
- ORA-01653錯誤是Oracle資料庫中常見的錯誤Oracle資料庫
- 政府網站中常見的成語錯誤網站
- JavaScript中常見的錯誤,你犯了幾個?JavaScript
- 關閉Druid中某些錯誤日誌列印UI
- net 日誌分析錯誤
- 日誌查詢錯誤
- Mabatis配置錯誤日誌BAT
- deleted事件監聽報錯delete事件
- SAP 錯誤日誌的調查
- vue3開發中常見的程式碼錯誤或者其他相關問題小文章2.0Vue
- PbootCMS中常見的錯誤提示及其解決方案boot
- 記一次線上報錯日誌問題排查
- MySQL 狂寫錯誤日誌MySql
- 開啟PHP的錯誤log日誌PHP
- JAVA中常見的經典報錯型別Java型別
- 資料分析中常見的錯誤是什麼(一)
- node錯誤處理與日誌
- kratos相關錯誤彙總
- 模型deleted事件監聽報錯解析模型delete事件
- python logger 列印日誌錯誤行數Python
- 【常見錯誤】--Nltk使用錯誤
- 基於ELK搭建MySQL日誌平臺的要點和常見錯誤MySql
- 遊戲基礎知識——“社交”設計相關的常見錯誤遊戲
- oracle alert日誌Oracle
- 前端錯誤監控與上報前端
- 2、MySQL錯誤日誌(Error Log)詳解MySqlError
- node專案錯誤處理與日誌
- mysql慢查詢和錯誤日誌分析MySql
- win10系統怎麼檢視系統錯誤日誌_win10如何檢視錯誤日誌Win10
- Linux MIPI 除錯中常見的問題Linux除錯
- ITMySQL錯誤日誌與通用查詢日誌圖文詳析jugMySql
- 如何用NodeJS讀取分析Nginx錯誤日誌NodeJSNginx
- Linux中常見的檔案讀寫錯誤問題及解決方法!Linux
- Springboot日誌相關Spring Boot