問題：監控不斷告警ORA-12609
Wed 10/14/2020 10:40 AM 12CRAC1-ALERT中出現ORA錯誤，請檢查 171- nt OS err code: 0 172- Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=xx)(PORT=1910)) 173-2020-10-14T10:29:26.605709+08:00 174-Errors in file /u01/app/oracle/diag/rdbms/bjivradg/bjivradg1/trace/bjivradg1_tt03_5501.trc: 175:ORA-12609: TNS: Receive timeout occurred 176-2020-10-14T10:29:26.605874+08:00 177-LGWR: Error 12609 closing archivelog file 'acscnprd' 178-TT03: Standby redo logfile selected for thread 1 sequence 4067 for destination LOG_ARCHIVE_DEST_3
ORA-12609???
這個報錯啥意思？ ORA-12609: TNS: Receive timeout occurred 接收超時！ 也就是說你傳輸或者接收的session 連接斷開了，然后Alert報錯ORA 12609 可能性是不是太多了？？？ 場景：12c主庫，有3個備庫！只有北京的備庫不間斷報錯？？？
可能性1，SQLNET參數？？？
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
$ cat sqlnet.ora
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
#SQLNET.ALLOWED_LOGON_VERSION=8
#sqlnet.allowed_logon_version_server=9
SQLNET.ALLOWED_LOGON_VERSION_SERVER=8
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8
SQLNET.INBOUND_CONNECT_TIMEOUT=600
SQLNET.EXPIRE_TIME= 5
SQLNET.RECV_TIMEOUT = 600
SQLNET.SEND_TIMEOUT = 600
接受超時時間（單位秒）
RECV_TIMEOUT
發送超時時間（單位秒）
SEND_TIMEOUT
https://docs.oracle.com/cd/E11882_01/network.112/e10835/sqlnet.htm#NETRF227
SQLNET.RECV_TIMEOUT
指定建立連接后數據庫服務器等待客戶端數據的時間（以秒為單位）。客戶端必須在該時間間隔內發送一些數據。
對於客戶端偶爾關閉或異常關閉的環境，建議設置此參數。如果客戶端未在指定的時間內發送任何數據，則數據庫服務器將記錄日志ORA-12535: TNS:operation timed out和消息到文件。沒有此參數，數據庫服務器可能會繼續等待來自可能已關閉或遇到問題的客戶端的數據。ORA-12609: TNS: Receive timeout occurredsqlnet.log
您還可以在客戶端設置此參數，以指定連接建立后客戶端等待來自數據庫服務器的響應數據的時間（以秒為單位）。如果沒有此參數，則客戶端可能會等待很長一段時間，以等待來自飽含請求的數據庫服務器的響應。如果選擇設置該值，則將該值設置為初始低值，然后根據系統和網絡容量進行調整。如有必要，將此參數與SQLNET.SEND_TIMEOUT參數一起使用。
SQLNET。SEND_TIMEOUT
目的
指定建立連接后數據庫服務器完成向客戶端的發送操作的時間（以秒為單位）。對於客戶端偶爾或異常關閉的環境，建議設置此參數。
如果數據庫服務器無法在指定的時間內完成發送操作，則它將記錄 ORA-12535: TNS:operation timed out 和 ORA-12608: TNS: Send timeout occurred消息到sqlnet.log文件。如果沒有此參數，則數據庫服務器可能會繼續向由於計算機故障或繁忙狀態而無法接收數據的客戶端發送響應。
您也可以在客戶端設置此參數，以指定客戶端在建立連接后完成向數據庫服務器發送操作的時間（以秒為單位）。如果沒有此參數，客戶端可能會繼續將請求發送到已經飽和了請求的數據庫服務器。如果選擇設置該值，則將該值設置為初始低值，然后根據系統和網絡容量進行調整。如有必要，將此參數與SQLNET.RECV_TIMEOUT參數一起使用
Archived: Dead Connection Detection (DCD) Explained (Doc ID 151972.1)
How To Automate Disconnection of Idle Sessions (Doc ID 159978.1)
Description of Parameter SQLNET.INBOUND_CONNECT_TIMEOUT (Doc ID 274303.1)
Oracle Net (SQL*Net) Timeout Parameters (Doc ID 1560775.1)
使用SQLNET.INBOUND_CONNECT_TIMEOUT參數以
秒為單位指定客戶端與數據庫服務器連接
並提供必要的身份驗證信息所允許的時間（以秒為單位）。
如果客戶端未能
在指定的時間內建立連接並完成身份驗證，則數據庫服務器將終止連接。
https://www.askmaclean.com/archives/12c-ttnn-tmon-new-background-process.html
但從版本12c開始 使用TTnn 例如TT00進程來負責async 異步的redo傳輸。 另一個后台進程TMON來負責做Redo transport monitor。
備庫SQLNET.ora
$ cat sqlnet.ora
# sqlnet.ora Network Configuration File: /opt/ora11g/product/11.2.3/db_1/network/admin/sqlnet.ora
# Generated by Oracle configuration tools.
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
SQLNET.EXPIRE_TIME=10
SQLNET.INBOUND_CONNECT_TIMEOUT=600
ADR_BASE = /u02/app/oracle
#TCP.VALIDNODE_CHECKING=yes
#TCP.INVITED_NODES=(10.35.179.134,172.31.150.70,172.31.150.71,10.35.179.142,10.35.179.129,10.35.179.9,172.31.150.81,172.30.19.240,172.30.19.247,172.29.147.79,10.35.179.135,172.31.153.141,172.30.8.230,172.30.19.188,10.35.181.152,10.35.179.49,10.35.179.10,172.30.19.19,172.31.150.152,10.35.179.247,172.29.147.69,10.35.179.242,10.35.179.15,172.30.19.122,172.30.19.250,172.31.150.103,10.35.179.215,172.31.150.76,172.31.150.92,172.31.150.93,172.31.150.155,172.31.150.117,172.31.150.118,172.31.150.119,172.31.150.120,172.31.150.121,172.31.150.122,172.31.150.123,172.29.147.91,10.35.179.241,10.35.180.17,10.35.179.61,10.35.179.15,172.30.19.120,172.31.153.151,172.30.8.9)
SQLNET.ALLOWED_LOGON_VERSION_SERVER=8
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8
SQLNET.INBOUND_CONNECT_TIMEOUT=600
SQLNET.EXPIRE_TIME= 5
可能性排除： 通過檢索文檔，信息都是加大這兩個參數的值，可以減少或避免這個問題！ 但是這個是之前的DBA,參數從60調整至600，但是報錯的頻率及次數並未降低，因此可以排除！！！
SQLNET.RECV_TIMEOUT = 600
SQLNET.SEND_TIMEOUT = 600
思路：加大這兩個參數后，例如原本50s就中斷了的信息，現在600s無法傳輸或者接收才超時，如果有用，那么報錯的頻率將減少！
可能性2，防火牆
通過操作系統檢查無防火牆！ 數據庫服務器一般也不配置防火牆，並且只有北京的DG有問題，其它地區DG無問題？？？ SQLNET.EXPIRE_TIME=5 oracle會間隔一定時間進行tcp探測，因此這種情況下，很少存在超時被防火牆策略斷開的情況。
可能性3，北京dg與其它dg有什么差異？？？
select INST_ID,dest_name,status,recovery_mode from gv$archive_dest_status where DEST_NAME in('LOG_ARCHIVE_DEST_3','LOG_ARCHIVE_DEST_5'); INST_ID DEST_NAME STATUS RECOVERY_MODE ---------- ------------------------------ --------- ----------------------- 1 LOG_ARCHIVE_DEST_3 VALID MANAGED REAL TIME APPLY 1 LOG_ARCHIVE_DEST_5 VALID MANAGED 3 LOG_ARCHIVE_DEST_3 VALID MANAGED REAL TIME APPLY 3 LOG_ARCHIVE_DEST_5 VALID MANAGED 2 LOG_ARCHIVE_DEST_3 VALID MANAGED REAL TIME APPLY 2 LOG_ARCHIVE_DEST_5 VALID MANAGED
DG重置遠程歸檔參數后，主庫觀察備庫連通性，無意中發現問題報錯的DG 是非實時應用！！！ 思路反思，如果是非實時應用，那么主庫只有切換歸檔，主庫才會真正傳輸數據！否則這個連接沒活干？？？
那么如果主庫長時間並未切換dg的情況下，是不是這個會話容易被斷開？？？
dg開始實施應用后，問題解決！ 不在出現該報錯。
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> recover managed standby database using current logfile disconnect;
Media recovery complete.
SQL> select INST_ID,dest_name,status,recovery_mode from gv$archive_dest_status where DEST_NAME in('LOG_ARCHIVE_DEST_3','LOG_ARCHIVE_DEST_5')
INST_ID DEST_NAME STATUS RECOVERY_MODE
---------- ------------------------------ --------- -----------------------
1 LOG_ARCHIVE_DEST_3 VALID MANAGED REAL TIME APPLY
1 LOG_ARCHIVE_DEST_5 VALID MANAGED REAL TIME APPLY
3 LOG_ARCHIVE_DEST_3 VALID MANAGED REAL TIME APPLY
3 LOG_ARCHIVE_DEST_5 VALID MANAGED REAL TIME APPLY
2 LOG_ARCHIVE_DEST_3 VALID MANAGED REAL TIME APPLY
2 LOG_ARCHIVE_DEST_5 VALID MANAGED REAL TIME APPLY
6 rows selected.