ORA-12609報錯分析
問題：監控不斷告警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 occurred176-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.