Oracle DCD配置緩解12170問題

 

Oracle Net是負責實現從客戶端到伺服器的重要元件。在連線和保持通訊過程中，Oracle Net都是擔負著重要的職責。在實際運維環境中，一些連線和通訊故障，都需要對於Oracle Net進行相應的調整控制工作。

進入11g之後，Oracle的alert log職能是在不斷的強化過程。ADR（Automatic Diagnostic Repository）的引入，將Oracle各個關鍵元件，如監聽器、資料庫日誌和Grid等告警跟蹤資訊進行重組，以資訊庫的形式加以組織。同時，除了原有的執行過程核心資訊，一些提示內容也會出現在alert log中。所以，作為運維人員，定期關注或者監控alert log中的關鍵資訊，可以幫助我們提高效能，解決日常運維問題。

 

1、問題說明

 

筆者管理的一套業務系統，尚在開發測試階段。系統本身架構比較簡單，屬於CS兩層架構，客戶端程式直接連線資料庫伺服器進行資料互動。Oracle資料庫版本為11.2.0.4。

 

 

Starting up:

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

With the Partitioning, OLAP, Data Mining and Real Application Testing options.

Windows NT Version V6.1 

CPU                 : 4 - type 8664, 4 Physical Cores

Process Affinity    : 0x0x0000000000000000

 

 

在資料庫巡檢過程中，看到alert log中反覆出現Oracle Net報錯提示。

 

 

Mon Jul 14 17:15:54 2014

 

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

Fatal NI connect error 12170.

 

  VERSION INFORMATION:

   TNS for 64-bit Windows: Version 11.2.0.4.0 - Production

   Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.4.0 - Production

   Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.4.0 - Production

  Time: 14-JUL-2014 17:15:54

  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: 60

    nt OS err code: 0

  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=172.17.22.43)(PORT=58793))

 

 

該型別提示不斷出現在alert log中，區別在於每次的client物件IP地址埠有區別。

 

2、問題分析

 

提示資訊出現的主要時間段就是白天工作時間，提示的主機IP地址經查就是測試使用者IP。系統客戶端非IE，以JDBC方式連入到資料庫中。Oracle ADR在11g中會自動將很多警告資訊寫入到alert log中。

從報錯資訊看，Fatal NI connect error 12170是與Oracle Net和TCP/IP網路相關。這個報錯資訊內容上，是Oracle強制斷開了與客戶端的連線關係，終止會話過程。

Oracle Client Process與Server Process是典型的一對一關係。在獨佔連線模式下，Client Process發起連線請求，透過監聽器建立起與Server Process的關係，此後兩者的關係就是“同生共死”管理。正常情況下，只有在Client Process主動終止連線的情況下，Server Process才會進行連線斷開動作。在主動中斷的過程中，Client Process會存在一個終止資訊回寫的動作。

在一些特殊的情況下，是可能出現異常中斷情況的。例如Client Process異常中斷、無響應或者在網路層面切斷。此外，一些網路防火牆設定也會自動的將長期閒置（或者認為閒置）的連線切斷。

如果客戶端與伺服器長期保持連線關係，比如使用PL/SQL Developer或者CS客戶端直連，兩者之間沒有資料傳遞。一些防火牆會自動監控這些閒置連線，如果閒置時間很長，防火牆會將這些連線自動打斷。而且，長期執行的查詢語句和JDBC方式連入的連線，出現斷開的機率更高。

以隨機從alert log中找到的一條報警記錄為例進行分析。

 

Mon Jul 14 17:21:38 2014

 

 

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

 

Fatal NI connect error 12170.

 

  VERSION INFORMATION:

   TNS for 64-bit Windows: Version 11.2.0.4.0 - Production

   Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.4.0 - Production

   Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.4.0 - Production

  Time: 14-JUL-2014 17:21:38

  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: 60

    nt OS err code: 0

  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=172.18.9.4)(PORT=3067))

 

 

幾個關鍵資訊需要注意，首先系統報錯資訊是在下午五點二十分左右發生的。也就是說，這個死連結是Oracle在這個時間點發現的。那麼這個連結是什麼時候建立起來的呢？

Oracle監聽器是負責所有遠端連線的中介元件。在執行日誌listener.log中，我們可以發現連線資訊。

 

14-JUL-2014 14:29:12 * (CONNECT_DATA=(CID=(PROGRAM=JDBC Thin Client)(HOST=__jdbc__)(USER=zhangsan))(SERVICE_NAME=sicsdb)(CID=(PROGRAM=JDBC Thin Client)(HOST=__jdbc__)(USER=zhangsan))) * (ADDRESS=(PROTOCOL=tcp)(HOST=172.18.9.4)(PORT=3067)) * establish * sicsdb * 0

 

 

注意：進行這種查詢操作，使用host IP地址外加埠號是最簡單快速的方法。這裡面，我們需要澄清一下這個port埠。我們連入伺服器的時候，也有一個埠號，那個是監聽器埠。Oracle伺服器端，監聽器伺候在特定埠等待請求連線。這個埠預設是1521。

但是，我們檢查listener.log資訊，可以發現確定的連線埠卻沒有事1521的。這個說明：在監聽器起到中介作用，通知Oracle例項Instance建立Server Process與Client Process之間關係之後，監聽器就不再承擔職責了。後續如身份驗證等操作，都是Client與Server直接進行溝通。兩者之間的埠，就不是1521了，而是重新分配的一個埠。

在一些Oracle古老版本中，還有對於1521埠共用的一些特性。隨著防火牆技術的發展和Oracle自身的變化，這個特性已經不需要了。

從listener.log資訊片段看，這個連結是從下午14:29建立出的。也就是說，連結持續了三個小時後，被異常中斷。

分析其他連線軌跡，的確可以發現所有連線均是維持2-3小時之後，被強制斷開。這種情況，就有理由認為是客戶端主機或者網路中防火牆自動清理連線功能的作用。

在Oracle端，解決方法就是採用Oracle Net DCD（Dead Connection Detect）來進行症狀緩解。

 

3、Oracle DCD

 

Oracle DCD是一種通訊查探技術，引入特性的初衷是解決死連結標記回收問題。一個Server Process對應一個Client Process，如果出現異常中斷的情況或者Client Process異常死亡。Server Process就需要進行事務回滾和資源回收。

DCD的原理很簡單，就是在Server與Client建立連線之後，以一個固定的週期從Server端給Client傳送一個空訊息。如果通訊線路正常，並且Client Process狀態正常，會自動回覆，這樣就確定了當前連線狀態正常。如果連線失敗，Oracle會將這個Server Process進行標記，交由伺服器端進行回收。

DCD對於長時間連線被斷開現象的意義在於：以固定的頻率維持Client與Server的通訊，這樣讓防火牆的等網路保護裝置不會將這個連線認為為死連結強制斷開。

配置DCD的方法比較簡單，也是圍繞sqlnet.ora引數檔案進行。

 

 

--sqlnet.ora

# This file is actually generated by netca. But if customers choose to

# install "Software Only", this file wont exist and without the native

# authentication, they will not be able to connect to the database on NT.

 

SQLNET.AUTHENTICATION_SERVICES = (NTS)

SQLNET.EXPIRE_TIME = 5

 

 

重新載入監聽器引數，之後啟動生效。預設情況下，我們是不能看到傳送空訊息記錄的。透過啟動Oracle Net Service的監聽機制，我們是可以檢視到空資料包傳送動作的。

 

4、結論

 

配置DCD，可以在一定程度上緩解由於長時間連線中斷造成的報錯問題。同時也可以排除發現潛在前端應用在資料庫連線方面的故障和問題。