Oracle 12c rman duplicate由于网卡offload引起备份文件坏块
Tags： ORA-19612ORA-19660ORA-19661ORA-19849Oraclerman备份恢复
前言:
最近，在使用rman duplicate进行备库环境搭建时，遇到了ORA-19849 19612坏块报错，最终分析是发现由于网络的配置导致。
问题:
在 ORACLE 12.2.0.1.180417 通过RMAN duplicate进行备库初始化，在复制文件的过程中，数据文件恢复失败，出现块迷失或者坏块错误
1 2 3 4 5 6 7 | 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
1 2 3 4 5 6 7 8 | SQL> select status,count(*) 2 from v$datafile_header 3 group by status; STATUS COUNT(*) --------------------- ---------- ONLINE 129 |
接着，我们对源库的数据文件进行坏块检测，并没有发现到坏块
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | 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模式，分析是否有更多详细的报错信息
1 2 | rman target 'sys/""'@sourceo auxiliary 'sys/""'@target debug trace=rmanDebug.trc |
从debug的日志里面，我们发现坏块是从读取通过网络传输的备份片里面产生的，怀疑很有可能是网络层面问题导致
1 2 | 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功能
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | [root@lhr ~]# ethtool -k eth0 | grep offload tcp-segmentation-offload: on udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off 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] macsec-hw-offload: off [fixed] hsr-tag-ins-offload: off [fixed] hsr-tag-rm-offload: off [fixed] hsr-fwd-offload: off [fixed] hsr-dup-offload: off [fixed] |
确认了可能是网络设置TCP OFFLOAD导致的问题之后，我们尝试通过文档提供方法进行修复，文档共提供了两个方法
- 使用压缩备份片的方式进行
- 网卡关闭TCP OFFLOAD功能
最后我们选择采用压缩备份片的方式进行rman duplicate，主要是根据以下考虑，由于关闭TCP OFFLOAD功能涉及网络基础架构，关闭该功能并没有进行充分的测试验证，可能带来潜在的网络性能影响，而使用压缩备份片的方式进行rman duplicate,只是从命令操作方式上进行调整，影响可控
随后，我们使用了压缩方式USING COMPRESSED BACKUPSET的duplicate,这一次，报错没有再次发生，RMAN-19849 19612问题得到解决
1 | duplicate target database for standby from active database nofilenamecheck USING COMPRESSED BACKUPSET; |
总结:
这个问题的分析解决过程还是比较诡异、曲折的，因为同环境上有4套数据库，使用相同的dupliate方式部署了2套是没有问题的，在部署第三套时才发生坏块问题，由于第三套的数据量较大达到TB级别，所以才触发了网络层面的问题，好在最后找到规避的方法。
