环境介绍：
操作系统：Redhat7.6
数据库版本：19.9
是否RAC：是
是否CDB：否
ASM或文件系统：ASM
ADG主备库节点数：均为2个
先简单介绍下故障，某天发现主库的节点1的日志无法传输至备库，而节点2传输正常。在经过相互ping，telnet及tnsping验证之后，确认网络正常。那究竟是咋回事呢？请听下文详细分解。
在主库查看传输通道状态，发现节点1的通道报ORA-01034:ORACLE not available：
去查看备库状态，确认都正常。为啥连不上呢？
是不是网络有问题？于是在经历两个节点相互ping，telnet及tnsping验证，确认网络网络正常，排除网络导致的问题。
我们尝试在主库节点sqlplus备库节点发现异常。
主库节点1sqlplus 备库节点1时报ORA-01034:ORACLE not available，跟通道报错一致。
并且从主库节点1sqlplus 备库节点2也一样的报ORA-01034。这就解释了为啥节点1为啥日志传输不过去了。但凡主库节点1能连上一个备库节点，都能把日志传输过去。因为通道里面设置的tnsname开启了failover，连接备库两个节点的VIP。
在主库节点2去sqlplus备库节点1时连接正常：
但是主库节点2去sqlplus备库节点2时也报ORA-01034。
通过多次sqlplus我们发现偶尔会报ORA-12637。
既然主备库都正常，网络也正常。初步怀疑是客户端出现问题。决定开启sqlnetlevel 16进行跟踪一下。
发现如下异常：
初步判断是由于OOB导致。
OOB是啥?其是19C客户端的新功能，如果网络上允许超出范围的中断，将触发服务器自动测试。
默认情况下处于启用状态。因此，当19c客户端连接到服务器时，它将触发服务器测试OOB，这可以在服务器端跟踪中看到。nsaccept：检查OOB支持。如果网络不支持OOB，则OOB检查将失败。连接也会失败。
故障解决方法：
在DB的sqlnet.ora中添加DISABLE_OOB=ON即可禁掉OOB自动检测。主备库所有节点添加之后，重启通道恢复正常。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/130043.html
摘要：李飞飞花名飞刀，阿里巴巴集团副总裁，高级研究员，达摩院首席数据库科学家，阿里云智能事业群数据库产品事业部负责人，杰出科学家。是阿里云的云原生数据库，目前已有非常深厚的技术积累。 阿里妹导读：云计算大潮来袭，传统数据库市场正面临重新洗牌的情境，包括云数据库在内的一批新生力量崛起，动摇了传统数据库的垄断地位，而由云厂商主导的云原生数据库则将这种改变推向了高潮。 云时代的数据库将面临怎样的...
DG备库读写测试方案 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; margin:0...
阅读 1346·2023-01-11 13:20
阅读 1684·2023-01-11 13:20
阅读 1132·2023-01-11 13:20
阅读 1858·2023-01-11 13:20
阅读 4099·2023-01-11 13:20
阅读 2704·2023-01-11 13:20
阅读 1385·2023-01-11 13:20
阅读 3594·2023-01-11 13:20
