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导致的问题之后,我们尝试通过文档提供方法进行修复,文档共提供了两个方法