1. 程式人生 > >解決連線被防火牆強制斷開,引起PL/SQL 和 Navicat Premium 客戶端頻繁連線卡機等一下問題

解決連線被防火牆強制斷開,引起PL/SQL 和 Navicat Premium 客戶端頻繁連線卡機等一下問題

本地IDE Console控制檯報錯:

java.net.SocketException: Connection reset by peer: socket write error

 

瀏覽器請求返回:

Status Code:504 Gateway Time-out

X-Swift-Error:orig response 5xx error

X-Swift-Error:forward peer connect close

 

PL/SQL 和 Navicat Premium 客戶端返回:

VERSION INFORMATION:

  TNS for Linux: Version 11.2.0.4.0 - Production

  TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production

  Time: 18-APR-2014 11:05:46

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

 

TNS-00507: Connection closed

    nt secondary err code: 0

    nt OS err code: 0

 

 

如果應該經常出現這樣的錯誤,主要問題可能出現在內網的防火牆設定,如果應用保持連線而長時間沒有操作,一些網路裝置就會斷開連線,解決方法就是通過設定服務端的sqlnet.ora檔案的sqlnet.expire_time引數,來主動向客戶端傳送檢測請求,如果客戶端還活著,則不做操 作,如果檢測發現客戶端的連線已經不存在或沒有反映,則回收這個session的資源。這樣,如果DCD的檢測時間小於防火牆設定的空閒連線 最大存活時間,那麼由於DCD檢測客戶端存活性需要從服務端傳送一個空包到客戶端,防火牆就會重新計算這個連線的空閒時間,就不會中斷這個會話了。設定DCD需要在服務端的sqlnet.ora檔案中新增以下資訊:

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

作者:風流搞技術

來源:CSDN

原文:https://blog.csdn.net/qq_34556414/article/details/81330604

版權宣告:本文為博主原創文章,轉載請附上博文連結!

 

F:\app\yzb\product\11.2.0\dbhome_1\NETWORK\ADMIN\sqlnet.ora :

 

# sqlnet.ora Network Configuration File: F:\app\yzb\product\11.2.0\dbhome_1\network\admin\sqlnet.ora

# Generated by Oracle configuration tools.

 

# 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)

 

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)

 

sqlnet.expire_time=1 //增加這個配置,單位為分鐘

 

通過設定引數為非零值(分鐘)來發送探測包以檢查客戶端的異常斷開。一旦探測包找到了異常的連線將返回錯誤,清除對應的server process

下面是引數使用的一些限制。(預設值為0,最小值0,建議值10。SQLNET.EXPIRE_TIME=10)

 

 

參考文章:

 

Oracle 監聽SQLNET.EXPIRE_TIME

2018年08月01日 14:55:59 風流搞技術 閱讀數:471更多

個人分類: Oracle 監聽

版權宣告:本文為博主原創文章,未經博主允許不得轉載。 https://blog.csdn.net/qq_34556414/article/details/81330604

在這邊資料庫加固有如下一個加固項,使用SQLNET.EXPIRE_TIME可以來斷開在session裡面超時的狀態為inactive的連線。

檢查是否設定超時時間

注意事項及影響

  • 作用:非活動會話超過10分鐘,連線斷開
  • 該項需要與業務側確認是否可以操作
  • 對於11g (如果有grid)只加固ORACLE使用者下的sqlnet.ora ,如果沒有則建立
  •  該項加固後,可能在alert 檔案中存在ORA-07445: exception encountered: core dump [snstimsane()+43] 報錯,(文件 ID 3934729.8),影響版本如下

 

 

序號

操作內容

操作步驟

責任人

時間

1

登陸主機

su - oracle

 

 

2

檢查監聽和資料庫狀態

lsnrctl status

sqlplus ‘/as sysdba’

select open_mode from v$database;

 

 

3

進入oracle_home

cd $ORACLE_HOME/network/admin

 

 

4

備份sqlnet.ora

cp sqlnet.ora sqlnet.ora_bak

 

 

5

編輯sqlnet.ora

增加下面的內容

SQLNET.EXPIRE_TIME = 10

 

 

6

檢查資料庫狀態

Select open_mode from v$database;

 

 

 

SQLNET.EXPIRE_TIME

Purpose

Use parameter SQLNET.EXPIRE_TIME to specify a the time interval, in minutes, to send a probe to verify that client/server connections are active. Setting a value greater than 0 ensures that connections are not left open indefinitely, due to an abnormal client termination. If the probe finds a terminated connection, or a connection that is no longer in use, it returns an error, causing the server process to exit. This parameter is primarily intended for the database server, which typically handles multiple connections at any one time.

Limitations on using this terminated connection detection feature are:

It is not allowed on bequeathed connections.

Though very small, a probe packet generates additional traffic that may downgrade network performance.

Depending on which operating system is in use, the server may need to perform additional processing to distinguish the connection probing event from other events that occur. This can also result in degraded network performance.

Default

0

Minimum Value

0

Recommended Value

10

Example

SQLNET.EXPIRE_TIME=10

 

目的

使用引數SQLNET.EXPIRE_TIME指定傳送探針以驗證客戶端/伺服器連線是否處於活動狀態的時間間隔(以分鐘為單位)。設定大於0的值可確保由於客戶端終止異常,連線無法無限期保持開啟狀態。如果探測發現終止連線或不再使用的連線,則會返回錯誤,導致伺服器程序退出。此引數主要用於資料庫伺服器,該伺服器通常一次處理多個連線。

使用此終止連線檢測功能的限制是:

遺留連線不允許這樣做。

雖然非常小,但探測資料包會產生額外的流量,可能會降低網路效能。

根據正在使用的作業系統,伺服器可能需要執行額外的處理以將連線探測事件與發生的其他事件區分開。這也可能導致網路效能下降。

 

預設

0

最低值

0

推薦值

10

SQLNET.EXPIRE_TIME = 10

 

 

DCD: Dead Connection Detection ,可以用於檢測、標記僵死而沒有斷開會session,再由PMON進行清理,釋放資源。開啟DCD,只需要在服務端的sqlnet.ora檔案中SQLNET.EXPIRE_TIME引數,單位為分鐘。 
如果時間達到這個值,server端就是發出一個”probe” packet 給客戶端,如要客戶斷是正常的,這個packet就被忽略,timer重新計時;如果客戶端異常中斷,則server端就會收到一個訊息,用以釋放連線。

 

SQLNET.EXPIRE_TIME設定客戶端連線會話超時時間(單位分鐘)

定期檢測客戶端是否還是活動的,設定為0不檢測

SQLNET.EXPIRE_TIME = 10

 

 

這裡是別人部落格的一個案例

關於sqlnet.expire_time.txt

 

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

 

Fatal NI connect error 12537, connecting to:

(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.xxx.xxx)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=xxxx.com)(CID=(PROGRAM=oracle)(HOST=xxx)(USER=oracle11g))))

 

  VERSION INFORMATION:

    TNS for Linux: Version 11.2.0.4.0 - Production

    TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production

  Time: 18-APR-2014 11:05:46

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

 

TNS-00507: Connection closed

    nt secondary err code: 0

    nt OS err code: 0

 

如果應該經常出現這樣的錯誤,主要問題可能出現在內網的防火牆設定,如果應用保持連線而長時間沒有操作,一些網路裝置就會斷開連線,解決方法就是通過設定服務端的sqlnet.ora檔案的sqlnet.expire_time引數,來主動向客戶端傳送檢測請求,如果客戶端還活著,則不做操 作,如果檢測發現客戶端的連線已經不存在或沒有反映,則回收這個session的資源。這樣,如果DCD的檢測時間小於防火牆設定的空閒連線 最大存活時間,那麼由於DCD檢測客戶端存活性需要從服務端傳送一個空包到客戶端,防火牆就會重新計算這個連線的空閒時間,就不會中斷這個會話了。設定DCD需要在服務端的sqlnet.ora檔案中新增以下資訊:

sqlnet.expire_time = 5

這個值的單位是分鐘,這裡設定的是每五分鐘服務端會向已連線資料庫的session所在的客戶端傳送一個空包,來檢測客戶端的存活性, 如果防火牆限制的空閒連線時間大於5分鐘,那麼連線到資料庫的會話就不會因為大於5分鐘的空閒時間而被中斷。這種方案完全可以解決這個問題,但這種方法需要重新註冊監聽。

 

--簡單做一個測試:

1.修改 sqlnet.ora檔案,加入:

SQLNET.EXPIRE_TIME=1

重啟監聽。

2.遠端開啟連線資料庫,不做任何操作。

3.在服務端執行如下命令:

# tcpdump -i eth0 -nnn host 192.168.xxx.xxx and port 1521

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

11:13:11.436128 IP 192.168.yyy.yyy.1521 > 192.168.xxx.xxx.64247: P 2119621137:2119621147(10) ack 2682317414 win 16060

11:13:11.636552 IP 192.168.xxx.xxx.64247 > 192.168.yyy.yyy.1521: . ack 10 win 63492

11:14:11.437488 IP 192.168.yyy.yyy.1521 > 192.168.xxx.xxx.64247: P 10:20(10) ack 1 win 16060

11:14:11.637790 IP 192.168.xxx.xxx.64247 > 192.168.yyy.yyy.1521: . ack 20 win 63482

11:15:11.437914 IP 192.168.yyy.yyy.1521 > 192.168.xxx.xxx.64247: P 20:30(10) ack 1 win 16060

11:15:11.637900 IP 192.168.xxx.xxx.64247 > 192.168.yyy.yyy.1521: . ack 30 win 63472

11:16:11.438691 IP 192.168.yyy.yyy.1521 > 192.168.xxx.xxx.64247: P 30:40(10) ack 1 win 16060

11:16:11.637143 IP 192.168.xxx.xxx.64247 > 192.168.yyy.yyy.1521: . ack 40 win 63462

11:17:11.439824 IP 192.168.yyy.yyy.1521 > 192.168.xxx.xxx.64247: P 40:50(10) ack 1 win 16060

11:17:11.639376 IP 192.168.xxx.xxx.64247 > 192.168.yyy.yyy.1521: . ack 50 win 63452

11:18:11.441028 IP 192.168.yyy.yyy.1521 > 192.168.xxx.xxx.64247: P 50:60(10) ack 1 win 16060

11:18:11.640484 IP 192.168.xxx.xxx.64247 > 192.168.yyy.yyy.1521: . ack 60 win 63442

11:19:11.441949 IP 192.168.yyy.yyy.1521 > 192.168.xxx.xxx.64247: P 60:70(10) ack 1 win 16060

11:19:11.641719 IP 192.168.xxx.xxx.64247 > 192.168.yyy.yyy.1521: . ack 70 win 63432

 

--可以看到每隔1分鐘,服務端向客戶端發起連線,檢測客戶端是否存在。

 

下面再整合一個案例

DCD: Dead Connection Detection ,可以用於檢測、標記僵死而沒有斷開會session,再由PMON進行清理,釋放資源。開啟DCD,只需要在服務端的sqlnet.ora檔案中新增SQLNET.EXPIRE_TIME引數,單位為分鐘。 如果時間達到這個值,server端就是發出一個”probe” packet 給客戶端,如要客戶斷是正常的,這個packet就被忽略,timer重新計時;如果客戶端異常中斷,則server端就會收到一個訊息,用以釋放連線。

 

DCD還可以用於防止防火牆的timeout,例如:

某個系統RMAN備份,在結束時,這裡是結束了,服務端和客戶端不存在資料的互動,報如下資訊:

released channel: dev_0

released channel: dev_1

released channel: dev_2

released channel: dev_3

released channel: dev_4

released channel: dev_5

released channel: dev_6

released channel: dev_7

released channel: dev_8

released channel: dev_9

released channel: dev_10

released channel: dev_11

RMAN-00571: ===========================================================

 

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

 

RMAN-00571: ===========================================================

 

RMAN-06004: ORACLE error from recovery catalog database:

ORA-03135: connection lost contact

ORACLE error from recovery catalog database:

ORA-03114: not connected to ORACLE

Is the rman catalog Database running on a different system than the Target Database?

If so, verify with the System Administrators what the TCP/IP timeout is set to.

If there is any firewall between two systems, set the value of SQLNET.EXPIRE_TIME to less than the TCP timeout value of the firewall.

Increase the value of SQLNET.EXPIRE_TIME in the sqlnet.ora file on both target servers if no firewall exists between two systems.

Increase the value of keepalive interval.

以上這個RMAN報錯例子就是由於防火牆設定timeout原因,當client和server在timeout時間內沒有資料傳輸的時候,會話就會被防火牆斷開。而設定SQLNET.EXPIRE_TIME引數,使其小於防火牆的timeout時間,就可以避免這一情況的發生

 

——————————————————————————————

 

ORA-03135: connection lost contact.

 

——————————————————————————————

 

某B/S架構的應用程式在測試過程中每隔1到2小時出現“錯誤資訊:ORA-03135: 連線失去聯絡的報錯”,詳細報錯資訊如下:

ORA-03135出現的原因較多,問題有可能出在網路裝置、作業系統、資料庫上,問題最有可能是由於網路閃段和防火牆配置所導致。

解決:經與網工確認,當前防火前未開啟長連線設定,開啟後問題解決。

補充一下長連線和短連線的概念:

①長連線的概念

長連線功能用於設定特定資料流的超長保持時間,讓資料流的會話連線保持時間不受全域性老化時間限制。其實這項特殊業務與目前業界的狀態防火牆的實現機制是存在矛盾的。

為保證內部網路的安全,防火牆上的各會話預設保持時間都相對較短,例如:預設情況下,TCP的保持時間為1200s,UDP的保持時間為120s。

正常情況下,當一個TCP會話的兩個連續報文到達防火牆的時間間隔大於該會話的保持時間時,為保證網路的安全性,防火牆將從會話表中刪除相應會話資訊。後續報文到達防火牆後,防火牆根據自身的轉發機制,丟棄該報文,導致連線中斷。在實際應用中,使用者需要查詢伺服器上的資料,這些查詢時間間隔遠大於TCP/UDP預設的會話保持時間。此時需要在防火牆上保持TCP連線一段相對較長的時間。當某會話的報文長時間沒有到達防火牆後再次到達時,仍然能夠通過防火牆,這種技術就是長連線。

②短連線的概念

某些應用頻繁發起連線,如果不縮短其會話保持時間,則會使防火牆的會話數爆漲,進而拖垮防火牆。保持太多的會話對防火牆沒有必要,相反,當系統資源過多地用在會話保持的話,會相應損害每秒生成會話的能力,這是一個同樣重要的效能指標。設定過高的會話數量,卻降低了每秒生成會話的能力,其結果,只能是保留一些永遠用不到的會話虛數而已。

因此,我們可以根據網路應用環境的實際需求,縮短某些會話的保持時間,從而減少防火牆的工作負荷,提高網路效能。

https://blog.csdn.net/qq_34556414/article/details/81330604

 

 

使用 SQLNET.EXPIRE_TIME 清除僵死連線

    資料庫連線的客戶端異常斷開後,其佔有的相應並沒有被釋放,如從v$session檢視中依舊可以看到對應的session處於inactive,且對應的伺服器程序也沒有釋放,導致資源長時間地被佔用,對於這種情形開該如何處理呢?SQLNET.EXPIRE_TIME對於這個問題我們提供瞭解決方案,專門用於清理那些異常斷開的情形,如網路異常中斷,客戶端異常掉電,異常重啟等。本文描述了設定SQLNET.EXPIRE_TIME引數以及演示死連線以及資源被釋放的情形。

 

1、理解SQLNET.EXPIRE_TIME引數
   Use parameter SQLNET.EXPIRE_TIME to specify a the time interval, in minutes, to send a probe to verify that client/server
   connections are active.
   Setting a value greater than 0 ensures that connections are not left open indefinitely, due to an abnormal client termination. 
   If the probe finds a terminated connection, or a connection that is no longer in use, it returns an error, causing the 
   server process to exit. 
   This parameter is primarily intended for the database server,which typically handles multiple connections at any one time.
   
   通過設定引數為非零值(分鐘)來發送探測包以檢查客戶端的異常斷開。一旦探測包找到了異常的連線將返回錯誤,清除對應的server process
   下面是引數使用的一些限制。(預設值為0,最小值0,建議值10。SQLNET.EXPIRE_TIME=10)
   Limitations on using this terminated connection detection feature are:
   
      It is not allowed on bequeathed connections.
      Though very small, a probe packet generates additional traffic that may downgrade network performance.
      Depending on which operating system is in use, the server may need to perform additional processing to distinguish
      the connection probing event from other events that occur. This can also result in degraded network performance.

 

2、Dead Connection Detection (DCD)與Inactive Sessions

Dead connections:
   These are previously valid connections with the database but the connection between the client and server processes has
   terminated abnormally.
   Examples of a dead connection:
   - A user reboots/turns-off their machine without logging off or disconnecting from the database.
   - A network problem prevents communication between the client and the server.
   
   In these cases, the shadow process running on the server and the session in the database may not terminate.
   
   Implemented by 
         * adding SQLNET.EXPIRE_TIME = <MINUTES> to the sqlnet.ora file 
   
   With DCD is enabled, the Server-side process sends a small 10-byte packet to the client process after the duration of 
   the time interval specified in minutes by the SQLNET.EXPIRE_TIME parameter.
   
   If the client side connection is still connected and responsive, the client sends a response packet back to the database
   server, resetting the timer..and another packet will be sent when next interval expires (assuming no other activity on 
   the connection).
   
   If the client fails to respond to the DCD probe packet
        * the Server side process is marked as a dead connection and 
        * PMON performs the clean up of the database processes / resources
        * The client OS processes are terminated
   
   NOTE: SQLNET.RECV_TIMEOUT can be set on the SERVER side sqlnet.ora file. This will set a timeout for the server process 
         to wait for data from the client process.

Inactive Sessions:
   These are sessions that remain connected to the database with a status in v$session of INACTIVE.
   Example of an INACTIVE session:
   - A user starts a program/session, then leaves it running and idle for an extended period of time.

 

3、配置SQLNET.EXPIRE_TIME

#對於SQLNET.EXPIRE_TIME的配置,需要修改sqlnet.ora,然後新增SQLNET.EXPIRE_TIME項
[[email protected] admin]$ more sqlnet.ora
sqlnet.expire_time = 1     #僅僅需要配置此項,後面的各項僅僅是為了生成跟蹤日誌,可省略
TRACE_LEVEL_SERVER = 16 
TRACE_FILE_SERVER = SERVER
TRACE_DIRECTORY_SERVER= /u01/app/oracle/network/trace 
TRACE_TIMESTAMP_ SERVER = ON 
TRACE_UNIQUE_SERVER = ON
DIAG_ADR_ENABLED=OFF

4、模擬及測試DCD連線

C:\Users\robinson.cheng>sqlplus scott/[email protected]    --->從windows客戶端發起連線

SQL*Plus: Release 11.2.0.1.0 Production on Tue Jun 25 09:57:59 2013

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

---Issued the sql to hold a lock
SQL> update emp set sal=sal*1.1 where deptno=20;   

5 rows updated.

--disabled the network adapter in VM setting
SQL> select * from dual;
select * from dual
       *
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 29522
Session ID: 15 Serial number: 447

--伺服器端環境   
SQL> select * from v$version where rownum<2;  
  
BANNER  
--------------------------------------------------------------------------------   
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production  

--在伺服器端檢視session的情況,SCOTT使用者的session狀態為INACTIVE
SQL> @comm_sess_users;

+----------------------------------------------------+
| User Sessions (All)                                |
+----------------------------------------------------+
Instance     SID Serial ID    Status Oracle User     O/S User O/S PID Session Program              Terminal       Machine
--------- ------ --------- --------- ----------- ------------ ------- -------------------------- ---------- -------------
ora11g        15       447  INACTIVE       SCOTT Robinson.Che   29522 sqlplus.exe                      PC39  TRADESZ\PC39
             125         5  INACTIVE         SYS       oracle    4734 [email protected] (TNS V1      pts/0    orasrv.com
             139         9    ACTIVE         SYS       oracle   29447 [email protected] (TNS V1      pts/4    orasrv.com

--Get the spid for user scott by SID
SQL> @my_spid_from_sid
Enter value for input_sid: 15
old   4: AND s.sid = &input_sid
new   4: AND s.sid = 15

   SID    SERIAL# SPID
------ ---------- ------------------------
    15        447 29522

--To find the locked object
SQL> @lock_obj

OBJECT_NAME||''||LOCKED_MODE||''||CTIME||''||C.SID||''||SERIAL#
------------------------------------------------------------------
EMP   3   14   15  447
EMP   3   83   15  447

--The trace file exists
SQL> ho ls -hltr /u01/app/oracle/network/trace/s*29522*
-rw-r----- 1 oracle oinstall 241K Jun 25 09:59 /u01/app/oracle/network/trace/server_29522.trc

--->try to issue another sql. the sql is blocked
SQL> set time on;
10:03:46 SQL> delete scott.emp where deptno=20;  
delete scott.emp where deptno=20
             *
ERROR at line 1:
ORA-01013: user requested cancel of current operation

--Check the server process for scott 
10:04:37 SQL> ho ps -ef | grep 29522 | grep -v grep
oracle   29522     1  0 09:58 ?        00:00:00 oracleora11g (LOCAL=NO)

--Could not reach to client from server.
10:06:51 SQL> ho ping 192.168.7.133
PING 192.168.7.133 (192.168.7.133) 56(84) bytes of data.
From 192.168.7.40 icmp_seq=2 Destination Host Unreachable
From 192.168.7.40 icmp_seq=3 Destination Host Unreachable
From 192.168.7.40 icmp_seq=4 Destination Host Unreachable
From 192.168.7.40 icmp_seq=6 Destination Host Unreachable
From 192.168.7.40 icmp_seq=7 Destination Host Unreachable
From 192.168.7.40 icmp_seq=8 Destination Host Unreachable

--此時總程序數為27個
10:15:08 SQL> select count(*) from v$process;

  COUNT(*)
----------
        27

--從09:58程序啟動開始到10:17:59程序依舊沒有被釋放
10:17:59 SQL> ho ps -ef | grep 29522 | grep -v grep
oracle   29522     1  0 09:58 ?        00:00:00 oracleora11g (LOCAL=NO)

-->At this time the server process was released
10:18:08 SQL> ho ps -ef | grep 29522 | grep -v grep

--程序釋放後此時程序總數變為26個
10:19:45 SQL> select count(*) from v$process;

  COUNT(*)
----------
        26

-->the lock was released
10:19:54 SQL> @lock_obj

no rows selected

--Author : Robinson
--Blog   : http://blog.csdn.net/robinson_0612

--scott使用者的session已經從v$session中被移除
10:20:03 SQL> @comm_sess_users;

+----------------------------------------------------+
| User Sessions (All)                                |
+----------------------------------------------------+

Instance     SID Serial ID    Status    Oracle User     O/S User O/S PID Session Program            Terminal    Machine
--------- ------ --------- --------- -------------- ------------ ------- -------------------------- -------- ----------
ora11g       125         5  INACTIVE            SYS       oracle    4734 [email protected] (TNS V1    pts/0 orasrv.com
             139         9    ACTIVE            SYS       oracle   29447 [email protected] (TNS V1    pts/4 orasrv.com

5、檢視SQLNET.EXPIRE_TIME是否啟用

#下面對跟蹤日誌過濾,可以看到09:58:02:853中提示開啟dead connection detection
[[email protected] trace]$ cat -n server_29522.trc |grep dead
    78  [25-JUN-2013 09:58:02:853] niotns: Enabling dead connection detection (1 min)

#下面的查詢中,在09:58:03 timer被啟動,10:18:26後,連線被徹底關閉(包括server process)    
[[email protected] trace]$ cat -n server_29522.trc |grep timer
   447  [25-JUN-2013 09:58:03:050] nstimstart: starting timer at 25-JUN-2013 09:58:03
   451  [25-JUN-2013 09:58:03:051] nsconbrok: timer created for connection
  4092  [25-JUN-2013 10:18:26:173] nstimarmed: timer is armed, with value 3833

#下面是starting timer的詳細資訊  
[[email protected] trace]$ head -451 server_29522.trc | tail -5
[25-JUN-2013 09:58:03:050] nstimstart: starting timer at 25-JUN-2013 09:58:03
[25-JUN-2013 09:58:03:051] nstimset: entry
[25-JUN-2013 09:58:03:051] nstimset: normal exit
[25-JUN-2013 09:58:03:051] nstimstart: normal exit
[25-JUN-2013 09:58:03:051] nsconbrok: timer created for connection 

#下面是timer被清除後的詳細資訊nstimclear: normal exit
[[email protected] trace]$ head -4097 server_29522.trc | tail -7
[25-JUN-2013 10:18:26:173] nstimarmed: entry
[25-JUN-2013 10:18:26:173] nstimarmed: timer is armed, with value 3833
[25-JUN-2013 10:18:26:173] nstimarmed: normal exit
[25-JUN-2013 10:18:26:173] nstimclear: entry
[25-JUN-2013 10:18:26:173] nstimclear: normal exit
[25-JUN-2013 10:18:26:173] nttctl: entry
[25-JUN-2013 10:18:26:173] nttctl: entry 

6、小結
a、DCD連線通常指使用者沒有正常斷開連線而重啟客戶端,關機以及網路問題導致客戶端無法與伺服器正常通訊所致的連線
b、相對於DCD連線,INACTIVE session則是使用者建立連線之後,尚未執行任何操作或操作已經完成但沒有斷開,等同於與處於idle狀態
c、無論是DCD連線,還是出於idle狀態的INACTIVE session,在v$session檢視呈現的都是INACTIVE狀態
d、對於使用resource_limit及profile配置後用戶session超出idle_time的情形,在v$session檢視呈現sniped狀態
e、當在sqlnet.ora配置檔案中設定了SQLNET.EXPIRE_TIME引數為非零值時,僵死連線在EXPIRE_TIME指定的時間後被清除
f、演示中僅僅設定EXPIRE_TIME為1分鐘,而實際的釋放時間接近20分鐘左右,什麼原因尚不清楚,有待進一步測試
g、設定SQLNET.EXPIRE_TIME為非零值之後,系統需要產生而外的開銷以及帶來網路效能的下降
h、對於需要及時釋放OS及DB資源的情形,Oracle建議使用resource_limit 及 profile 限制使用者連線的同時並設定SQLNET.EXPIRE_TIME為非零值 
i、Reference: [ID 206007.1] [ID 395505.1] [ID 601605.1] [ID 151972.1]

https://www.cnblogs.com/dyllove98/archive/2013/06/27/3159734.html

https://blog.csdn.net/leshami/article/details/9188379