Oracle-Rman duplicate文件坏块问题处理ORA-19849 19612

前言:

最近，在使用rman duplicate进行备库环境搭建时，遇到了ORA-19849 19612坏块报错，最终分析是发现由于网络的配置导致。

问题:

在 ORACLE 12.2.0.1.180417 通过RMAN duplicate进行备库初始化，在复制文件的过程中，数据文件恢复失败，出现块迷失或者坏块错误

RMAN-03002: failure of Duplicate Db command at 11/18/2022 15:45:06
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
ORA-19660: some files in the backup set could not be verified
ORA-19661: datafile 8 could not be verified
ORA-19849: error while reading backup piece from service yjzxpr
ORA-19612: datafile 8 not restored due to missing or corrupt data

问题原因:

网卡开启了TCP OFFLOAD(TCP网络卸载)功能，导致在网络传输过程中出现损坏

问题解决:

• 使用备份压缩方式进行rman duplicate

• 禁用网卡的tcp offload功能

问题分析:

出现这个报错，我们首先怀疑是源库的数据文件出现了问题，所以检查了数据文件的状态，但源库的数据文件全都是online

SQL> select status,count(*)
  2  from v$datafile_header
  3  group by status;
​
STATUS                  COUNT(*)
--------------------- ----------
ONLINE                       129

接着，我们对源库的数据文件进行坏块检测，并没有发现到坏块

rman target /
run {
allocate channel d1 type disk;
allocate channel d2 type disk;
allocate channel d3 type disk;
allocate channel d4 type disk;
backup validate check logical database;
release  channel d1;
release  channel d2;
release  channel d3;
release  channel d4;
}
---没有检测到坏块
SQL> select * from V$DATABASE_BLOCK_CORRUPTION ;
​
no rows selected
​
SQL>

到这里，我们可以初步排除是源库数据文件问题所导致的

接下来，我们使用debug模式，分析是否有更多详细的报错信息

rman target 'sys/""'@sourceo  auxiliary 'sys/""'@target debug trace=rmanDebug.trc

从debug的日志里面，我们发现坏块是从读取通过网络传输的备份片里面产生的，怀疑很有可能是网络层面问题导致

Corrupt block 747838 found during reading backup piece, file=network, corr_type=3
Continuing reading piece network, no other copies available.

同时，从Oracle mos官方上也发现产生相关问题的可能解决方法

案例一:RMAN Active Duplicate Fails with ORA-19837 ORA-19849 ORA-19850 (Doc ID 2451611.1)

根据文档的描述，如果目标数据库RMAN配置了加密，可能导致该问题的发生，解决的方法是关闭加密配置，但我们的数据库的加密已经关闭，不匹配该问题场景

案例二:ORA-19612 Error Trying To Duplicate Database With Rman (Doc ID 1361914.1)

根据文档的描述，可能由于网络设置，外部超时和防火墙设置，如"SQLNet修复"和"SQLNet深度数据包检查"导致，解决方法是手工检验，修复问题备份片，再重新尝试传输到目标端，该文档提供的信息有限，并且当前环境网络只通过交换机，并没有经过防火墙

案例三:ORA-19660 ORA-19661 DURING BACKUP VALIDATION (NFS) (Doc ID 1921662.1)

根据文档的描述，在通过NFS进行备份片存储时，可能导致备份片出现坏块的情况，由于网卡配置了TCP OFFLOAD功能

注:TCP OFFLOAD是指将本该在操作系统进行的一些大数据包处理(如TCP分段、IP分片、重组、checksum、TCP协议处理等)放到网卡硬件中去做， 降低系统 CPU 消耗的同时，提高处理的性能

该文档可以借鉴的类似地方是通过网络进行备份片传输的过程中，出现了备份片坏块，与之前我们通过debug分析读取通过网络传输的备份片出现坏块比较相似，并且提供了相对具体的网络配置可能问题

接下来我们检查服务器的网卡是否配置了TCP OFFLOAD功能，发现了服务器的网卡的确开启了tcp offload功能

ethtool -k em4 | grep offload
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on [fixed]
tx-vlan-offload: on [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]

确认了可能是网络设置TCP OFFLOAD导致的问题之后，我们尝试通过文档提供方法进行修复，文档共提供了两个方法

• 使用压缩备份片的方式进行

• 网卡关闭TCP OFFLOAD功能

最后我们选择采用压缩备份片的方式进行rman duplicate，主要是根据以下考虑，由于关闭TCP OFFLOAD功能涉及网络基础架构，关闭该功能并没有进行充分的测试验证，可能带来潜在的网络性能影响，而使用压缩备份片的方式进行rman duplicate,只是从命令操作方式上进行调整，影响可控

随后，我们使用了压缩方式USING COMPRESSED BACKUPSET的duplicate,这一次，报错没有再次发生，RMAN-19849 19612问题得到解决

duplicate target database for standby from active database nofilenamecheck USING COMPRESSED BACKUPSET;

总结:

这个问题的分析解决过程还是比较诡异、曲折的，因为同环境上有4套数据库，使用相同的dupliate方式部署了2套是没有问题的，在部署第三套时才发生坏块问题，由于第三套的数据量较大达到TB级别，所以才触发了网络层面的问题，好在最后找到规避的方法。