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 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.