List Bakcup在catalog的不同顯示問題

環(huán)境：

Oracle database 10.2.0.5
Primary RAC+ASM
Standby Single Instance+Non-ASM
Catalog
OS Oracle Linux 6

1.近日遇到一個(gè)小問題，在standby上連接controlfile進(jìn)行全庫(kù)備份，備份完成后，通過list bakcup，查詢到的數(shù)據(jù)文件路徑是“u01/data/****”

[$ rman target /
Recovery Manager: Release 10.2.0.5.0 - Production on Mon Sep 5 15:39:55 2016
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: ORA10G (DBID=4146617466, not open)
RMAN> backup database;
Starting backup at 05-SEP-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=160 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/u01/data/datafilesystem.259.827745351
input datafile fno=00002 name=/u01/data/datafileundotbs1.260.827745359
input datafile fno=00004 name=/u01/data/datafileundotbs2.263.827745369
input datafile fno=00003 name=/u01/data/datafilesysaux.261.827745363
input datafile fno=00005 name=/u01/data/datafileusers.264.827745371
......
Finished backup at 05-SEP-16
RMAN> list backup;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
5 Full 202.54M DISK 00:00:11 05-SEP-16
BP Key: 5 Status: AVAILABLE Compressed: NO Tag: TAG20160905T152357
Piece Name: /u01/app/database/dbs/06rf26kf_1_1
List of Datafiles in backup set 5
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 345345 05-SEP-16 /u01/data/datafilesystem.259.827745351
2 Full 345345 05-SEP-16 /u01/data/datafileundotbs1.260.827745359
3 Full 345345 05-SEP-16 /u01/data/datafilesysaux.261.827745363
4 Full 345345 05-SEP-16 /u01/data/datafileundotbs2.263.827745369
5 Full 345345 05-SEP-16 /u01/data/datafileusers.264.827745371 <<<<<<<<<<<<<<<<</u01/data/

2. 但是在連接到catalog，并sync之后，發(fā)現(xiàn)數(shù)據(jù)文件的路徑變成“+DATA/ora10g/datafile/***”， 這是Primary數(shù)據(jù)庫(kù)的實(shí)際路徑。 

$ rman target / catalog rman/rman@catalog
RMAN> list backup;
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
157 Full 202.54M DISK 00:00:11 05-SEP-16
BP Key: 159 Status: AVAILABLE Compressed: NO Tag: TAG20160905T152357
Piece Name: /u01/app/database/dbs/06rf26kf_1_1
List of Datafiles in backup set 157
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 345345 05-SEP-16 +DATA/ora10g/datafile/system.259.827745351
2 Full 345345 05-SEP-16 +DATA/ora10g/datafile/undotbs1.260.827745359
3 Full 345345 05-SEP-16 +DATA/ora10g/datafile/sysaux.261.827745363
4 Full 345345 05-SEP-16 +DATA/ora10g/datafile/undotbs2.263.827745369
5 Full 345345 05-SEP-16 +DATA/ora10g/datafile/users.264.827745371

3. 為什么會(huì)發(fā)生這種情況呢？

這個(gè)問題是由于Standby數(shù)據(jù)庫(kù)創(chuàng)建過程中，standby沒有使和primary相同的ASM存儲(chǔ)，及ASM路徑，而是使用的文件系統(tǒng)存放datafile。

這會(huì)涉及到db_file_name_convert和log_file_name_convert兩個(gè)參數(shù)。

其實(shí)，在standby controlfile中，數(shù)據(jù)文件和archive log文件的記錄名稱還是以“+DATA/ora10g/datafile/***”存在的。

只是每次訪問的時(shí)候，在standby中，都會(huì)默認(rèn)通過參數(shù)db_file_name_convert和log_file_name_convert進(jìn)行轉(zhuǎn)換的。

這樣，我們看到的都是“u01/data/****”。

4. 而回到我們的問題，由于catalog獲取的都是control file中的信息，并沒有db_file_name_convert和log_file_name_convert的轉(zhuǎn)換，所以，在catalog中，看到的數(shù)據(jù)文件，即使是通過standby備份的，依然也是以“+DATA/ora10g/datafile/***”名稱存儲(chǔ)的。

而在不連接catalog的時(shí)候，通過list bakcup查詢，就會(huì)發(fā)現(xiàn)，參數(shù)db_file_name_convert和log_file_name_convert在其中干預(yù)。進(jìn)而查詢到的結(jié)果是“u01/data/****”。

這里我們可以通過實(shí)驗(yàn)，來證明是否是db_file_name_convert和log_file_name_convert影響的結(jié)果的輸出

5. 我們?nèi)∠麉?shù)db_file_name_convert和log_file_name_convert的設(shè)定，然后在次在本地，通過control file的方式連接RMAN進(jìn)行查詢，結(jié)果如下：

$ rman target /
RMAN> list backup;
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
8 Full 202.54M DISK 00:00:06 05-SEP-16
BP Key: 8 Status: AVAILABLE Compressed: NO Tag: TAG20160905T154014
Piece Name: /u01/app/database/dbs/09rf27iu_1_1
List of Datafiles in backup set 8
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 345345 05-SEP-16 +DATA/ora10g/datafile/system.259.827745351
2 Full 345345 05-SEP-16 +DATA/ora10g/datafile/undotbs1.260.827745359
3 Full 345345 05-SEP-16 +DATA/ora10g/datafile/sysaux.261.827745363
4 Full 345345 05-SEP-16 +DATA/ora10g/datafile/undotbs2.263.827745369
5 Full 345345 05-SEP-16 +DATA/ora10g/datafile/users.264.827745371 <<<<<<<<<<<<<沒有db_file_name_convert的干預(yù)，顯示的結(jié)果就是“+DATA/ora10g/datafile/***”
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
9 Full 14.64M DISK 00:00:01 05-SEP-16
BP Key: 9 Status: AVAILABLE Compressed: NO Tag: TAG20160905T154014
Piece Name: /u01/app/database/dbs/0arf27j5_1_1
Standby Control File Included: Ckp SCN: 345345 Ckp time: 05-SEP-16
SPFILE Included: Modification time: 05-SEP-16

6. 通過上面的實(shí)驗(yàn)說明，standby上備份，和主庫(kù)是完全相同的。也可以通過standby的備份直接restore到primary數(shù)據(jù)庫(kù)。只是在list backup顯示時(shí)，由于db_file_name_convert的干預(yù)，結(jié)果有差異。

7. 其實(shí)這個(gè)問題，我們也可以通過查詢v$datafile，來看db_file_name_convert是否影響了數(shù)據(jù)文件名的輸出：

在db_file_name_convert設(shè)置的情況下，查詢standby數(shù)據(jù)庫(kù) 

SQL> select name from v$datafile;
NAME
------------------------------
/u01/data/datafilesystem.259.827745351
/u01/data/datafileundotbs1.260.827745359
/u01/data/datafilesysaux.261.827745363
/u01/data/datafileundotbs2.263.827745369
/u01/data/datafileusers.264.827745371

在沒有設(shè)置參數(shù)db_file_name_convert的情況下，查詢standby數(shù)據(jù)庫(kù) 

SQL> select name from v$datafile;
NAME
--------------------------------
+DATA/ora10g/datafile/system.259.827745351
+DATA/ora10g/datafile/undotbs1.260.827745359
+DATA/ora10g/datafile/sysaux.261.827745363
+DATA/ora10g/datafile/undotbs2.263.827745369
+DATA/ora10g/datafile/users.264.827745371