轉自：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連接一段相對較長的時間。當某會話的報文長時間沒有到達防火牆後再次到達時，仍然能夠通過防火牆，這種技術就是長連接。
②短連接的概念
某些應用頻繁發起連接，如果不縮短其會話保持時間，則會使防火牆的會話數爆漲，進而拖垮防火牆。保持太多的會話對防火牆沒有必要，相反，當系統資源過多地用在會話保持的話，會相應損害每秒生成會話的能力，這是一個同樣重要的性能指標。設定過高的會話數量，卻降低了每秒生成會話的能力，其結果，只能是保留一些永遠用不到的會話虛數而已。
因此，我們可以根據網絡應用環境的實際需求，縮短某些會話的保持時間，從而減少防火牆的工作負荷，提高網絡性能。
————————————————
版權聲明：本文爲CSDN博主「富士康質檢員張全蛋」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_34556414/article/details/81330604