记录一则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.模拟环境
查询本次测试迁移的表空间对应数据文件信息:
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定义的目录。
最新文章
- ExtJS 4.2 组件的查找方式
- xcode6 使用MJRefresh,Too many arguments to function call, expected 0, have *
- xcopy中提示“无效的参数数量”的解决方法
- js-url打开方式
- cocos2d-x 坐标系
- Hadoop 在ubuntu系统上的搭建[图解]
- oracle - redo 损坏或删除处理方法
- [HDOJ2473]Junk-Mail Filter(并查集,删除操作,马甲)
- 【译】 AWK教程指南 附录A-Patterns
- stagefright框架(五)-Video Rendering
- IDL 矩阵运算
- vue 使用瞬间
- Busybox制作ARM(iTOP4412) 根文件系统
- Python 零基础 快速入门 趣味教程 (咪博士 海龟绘图 turtle) 7. 条件循环
- C# 3.0 / C# 3.5 自动属性
- chrome浏览器调试报错:Failed to load resource: the server responsed width a status of 404 (Not Found)…http://127.0.0.1:5099/favicon.ico
- 面试问题总结二(技术能力-PHP)----Ⅱ
- javascript和php使用ajax通信传递JSON
- docker rmi 详解
- pip运行报错Fatal error in launcher: Unable to create process using pip.exe