記錄一則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定義的目錄。