记录一则xtts测试遇到的诡异现象

Posted 2021-01-27 jyzhao

背景：在一次xtts的测试中遇到因源库数据文件名称包含特殊字符导致表空间全量备份缺失文件，之所以说是诡异现象，是因为xtts的全备日志不报任何错误，在恢复阶段才发现缺少文件，这个缺陷比较隐晦，尤其在迁移的表空间较多的场景下，不注意的话很难第一时间发现。
环境：客户环境是AIX 6.1 + Oracle 10.2.0.3，使用xtts脚本2.0版本，本文在测试环境OEL 5.7 + Oracle 10.2.0.5 下，使用xtts脚本3.0实验，同样可以重现这个现象，说明是普遍现象。

• 1.模拟环境
• 2.重现问题
• 3.解决方法

1.模拟环境

查询本次测试迁移的表空间对应数据文件信息：
set lines 180
col file_name for a55
select file_id, file_name, status, online_status from dba_data_files where tablespace_name in (‘DBS_D_JINGYU‘,‘DBS_I_JINGYU‘);

[email protected]> select file_id, file_name, status, online_status from dba_data_files where tablespace_name in (‘DBS_D_JINGYU‘,‘DBS_I_JINGYU‘);

   FILE_ID FILE_NAME                                               STATUS    ONLINE_
---------- ------------------------------------------------------- --------- -------
         5 /oradata/orcl/dbs_d_jingyu01.dbf                        AVAILABLE ONLINE
         6 /oradata/orcl/dbs_i_jingyu01.dbf                        AVAILABLE ONLINE
         7 /oradata/orcl/dbs_d_jingyu02.dbf                        AVAILABLE ONLINE
         8 /oradata/orcl/dbs_d_jingyu03.dbf                        AVAILABLE ONLINE
         9 /oradata/orcl/dbs_d_jingyu04.dbf                        AVAILABLE ONLINE
        10 /oradata/orcl/dbs_d_jingyu05.dbf                        AVAILABLE ONLINE
        11 /oradata/orcl/dbs_d_jingyu06.dbf                        AVAILABLE ONLINE
        12 /oradata/orcl/dbs_d_jingyu07.dbf                        AVAILABLE ONLINE
        13 /oradata/orcl/dbs_d_jingyu08.dbf                        AVAILABLE ONLINE
        14 /oradata/orcl/                                          AVAILABLE ONLINE
            dbs_d_jingyu09.dbf

        15 /oradata/orcl/                                          AVAILABLE ONLINE
           dbs_d_jingyu10.dbf


11 rows selected.

发现14和15号文件本身名字就包含特殊字符，导致显示发生折行。

2.重现问题

此时直接测试xtts备份，就会发现虽然日志不会有任何报错，但实际上备份跑完之后，发现dbs_d_jingyu这个表空间整个都没有成功备份出来，只有其他表空间备份成功，比如我这里实验环境就是只有dbs_i_jingyu表空间的数据文件成功备份：

[[email protected] xtts]$ nohup sh full_backup.sh > full_backup.log &
[[email protected] src_backup]$ ls -lrth
total 31M
-rw-rw---- 1 ora10 1000 31M Dec 16 23:26 DBS_I_JINGYU_6.tf

3.解决方法

需要处理名字含特殊符号的数据文件，我这里采用的方法是copy备份这些数据文件，然后停机（一般业务闲时操作影响应该也不大，看业务重要程度来决定）offline相关数据文件，切换到copy副本并恢复成功，最后online数据文件，核心步骤参考如下：

RMAN>
backup as copy datafile 14 format ‘/oradata/orcl/dbs_d_jingyu09.dbf‘;  
backup as copy datafile 15 format ‘/oradata/orcl/dbs_d_jingyu10.dbf‘;  

list copy of datafile 14,15; 

--SQL>alter database datafile 14,15 offline;
sql ‘alter database datafile 14,15 offline‘;

switch datafile 14,15 to copy;
recover datafile 14,15;

--SQL>alter database datafile 14,15 online;
sql ‘alter database datafile 14,15 online‘;

最后查询本次测试迁移的表空间对应数据文件信息，已经显示正常，再次去xtts备份就可以正常备份出dbs_d_jingyu表空间的数据文件。

附录：
本文的测试环境是通过在添加数据文件时，利用类似这样的不规范操作模拟实现的：

[email protected]> alter tablespace dbs_d_jingyu add datafile ‘/oradata/orcl/
  2  dbs_d_jingyu10.dbf‘ size 10M;

Tablespace altered.

测试过这种情况下rman去备份是可以成功的，但xtts脚本备份就有问题，应该算是xtts的脚本缺陷，但是对于这类不规范的情况还是要尽可能避免。
所以建议以后xtts的准备工作多加一项数据文件数量的检查比对，及早发现这类情况提前处置：

select count(1) from dba_data_files where tablespace_name in (‘DBS_D_JINGYU‘,‘DBS_I_JINGYU‘);

还有一个需要注意的地方，如果是后发现想进行增量处理未备份的数据文件，需要确保先把之前已经备份成功的文件保存好，因为实验中发现xtts如果重新跑full_backup.sh脚本会自动清空dfcopydir定义的目录。