Oracle alert日誌中出現：‘Fatal NI connect error 12170’

按期檢查數據庫alert log信息，是咱們進行數據庫平常維護、巡檢和故障排除的重要工做手段。數據庫系統「帶病運行」、「負傷運行」每每是「小病致死」的主要殺手。所謂「防患於未然」就須要數據庫管理員從平常的小事微情入手，時刻了解系統運行狀況，並儘早進行處理。

本文主要介紹筆者使用Oracle 11gR2過程當中日誌巡檢中出現的問題，雖然最後沒有獲得圓滿解決。記錄下來，留待須要朋友待查。

一、問題說明

筆者使用的一套開發環境，數據庫版本是11gR2，小版本號爲11.2.0.4。

SQL> select * from v$version;

BANNER

--------------------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

PL/SQL Release 11.2.0.4.0 - Production

CORE    11.2.0.4.0 Production

TNS for Linux: Version 11.2.0.4.0 - Production

NLSRTL Version 11.2.0.4.0 – Production

在巡檢數據庫alert log過程當中，發現一些錯誤提示。

Tue May 19 23:04:55 2015

*************************************

Fatal NI connect error 12170.

  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: 19-MAY-2015 23:04:55

  Tracing not turned on.

  Tns error struct:

    ns main err code: 12535

   

TNS-12535: TNS:operation timed out

    ns secondary err code: 12560

    nt main err code: 505

   

TNS-00505: Operation timed out

    nt secondary err code: 110

    nt OS err code: 0

  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=172.xx.xx.xx)(PORT=50741))

相同類型錯誤在日誌中反覆出現，天天出現頻率在10條左右，區別在於每次的Host對應IP地址不一樣。

二、問題分析

這類型錯誤在11gR2版本中常常出現。筆者以前的一些投產系統中，也經常出現這樣的問題。當前進行開發的系統架構比較傳統，是一個典型CS架構方式。客戶端桌面應用是一個富客戶端軟件，全部業務邏輯都在客戶端。客戶端直接鏈接數據庫。

這種架構方式是比較傳統的方式，行業內對於這種方式的缺陷已經討論不少年了。單從數據庫角度看，這樣的架構方式意味着更加多的數據庫鏈接數量和更加頻繁的訪問結構。

利用IP地址，咱們能夠從監聽器日誌listener.log中，能夠定位到這個IP地址鏈接是何時鏈接過來的。

[oracle@localhost trace]$ pwd

/u01/app/diag/tnslsnr/localhost/listener/trace

[oracle@localhost trace]$ cat listener.log | grep 172. xx.xx.xx

19-MAY-2015 13:51:10 * (CONNECT_DATA=(CID=(PROGRAM=JDBC Thin Client)(HOST=__jdbc__)(USER=visvim))(SERVICE_NAME=sicsdb)) * (ADDRESS=(PROTOCOL=tcp)(HOST=172.xx.xx.xx)(PORT=50741)) * establish * sicsdb * 0

從MOS上的信息反饋看，這個類型錯誤提示是一種正常的Oracle工做機制。當客戶端進程Client Process與服務器進程Server Process創建聯繫以後，二者就造成了「同生共死」的關係（專有鏈接模式）。除非客戶端主動發起中斷或者Server Process被異常kill。

在實際運行環境中，這種理想狀態經常被打破。若是Client Process只是保持鏈接，不執行語句，會話就處於idle狀態。這種鏈接很容易被諸如防火牆等網絡層面設備切斷。

在Oracle11gR2中，若是長期沒有鏈接動做的Server Process被外力切斷，Oracle就會自動將信息做爲提示錯誤寫入到alert log中，做爲一種提示。在11R1版本中，這種信息是會寫入到sqlnet.log中。

三、問題解決措施

概括MOS和網絡中的各類方法，大致有兩重策略，分別爲使用DCD和禁用ADR。

DCD全稱Dead Connection Detection，是一種基於主動測探方式檢查Oracle殭屍客戶端進程Client Process的策略。配置DCD的關鍵是設置sqlnet.expire_time參數在SQL Net體系下，Oracle會依據這個時間間隔給全部的Client Process發送網絡通訊包，用來肯定Client是否存活。

正是藉助這個包通訊，可讓防火牆認爲這個網絡鏈接仍是處在active狀態，不會進行強制斷開動做。相似的機制還有Linux上的tcp keep live機制，也是使用相似的策略進行檢查。

[oracle@localhost trace]$ cd /u01/app/oracle/network/admin/

[oracle@localhost admin]$ ls -l

total 16

-rw-r--r--. 1 oracle oinstall  343 Sep  2  2014 listener.ora

drwxr-xr-x. 2 oracle oinstall 4096 Jun 16  2014 samples

-rw-r--r--. 1 oracle oinstall  381 Dec 17  2012 shrept.lst

-rw-r--r--. 1 oracle oinstall    0 Sep  2  2014 sqlnet.ora

-rw-r-----. 1 oracle oinstall  308 Sep  5  2014 tnsnames.ora

[oracle@localhost admin]$ cat sqlnet.ora 

[oracle@localhost admin]$ cat sqlnet.ora 

sqlnet.expire_time=10

另外一種方式也是Oracle推薦的，就是關閉11g的ADR機制。ADR（Automatic Diagnostic Repository）是Oracle進行自動診斷、自動提醒的工具組件。Oracle認爲若是用戶不須要在SQL Net組件中應用ADR，能夠再sqlnet.ora中進行配置關閉。

[oracle@localhost admin]$ cat sqlnet.ora 

sqlnet.expire_time=10

DIAG_ADR_ENABLED = OFF

DIAG_ADR_ENABLED_LISTENER=OFF

以後，從新reload監聽器配置，或者重啓監聽器。

[oracle@localhost admin]$ lsnrctl reload

LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 21-MAY-2015 10:13:34

Copyright (c) 1991, 2013, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))

四、結論

數據庫「Fatal NI connect error 12170」問題，從本質上是因爲長鏈接數據庫交互方式形成的，嚴格意義上不該算什麼錯誤問題。若是是一些三層架構體系應用，能夠考慮使用鏈接池進行動態資源調配的方式，對問題進行緩解。

 

轉發自：https://www.linuxidc.com/Linux/2015-05/118004.html