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

背景：在一次xtts的测试中遇到因源库数据文件名称包含特殊字符致使表空间全量备份缺失文件，之因此说是诡异现象，是由于xtts的全备日志不报任何错误，在恢复阶段才发现缺乏文件，这个缺陷比较隐晦，尤为在迁移的表空间较多的场景下，不注意的话很难第一时间发现。
环境：客户环境是AIX 5.3 + 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');

SYS@orcl> 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表空间的数据文件成功备份：

[oracle@db10 xtts]$ nohup sh full_backup.sh > full_backup.log &
[oracle@db10 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表空间的数据文件。

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

SYS@orcl> 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定义的目录。