環境:
1.近日遇到一個小問題,在standby上連接controlfile進行全庫備份,備份完成后,通過list bakcup,查詢到的數據文件路徑是“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之后,發現數據文件的路徑變成“+DATA/ora10g/datafile/***”, 這是Primary數據庫的實際路徑。
$ 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.8277453713. 為什么會發生這種情況呢?
這個問題是由于Standby數據庫創建過程中,standby沒有使和primary相同的ASM存儲,及ASM路徑,而是使用的文件系統存放datafile。
這會涉及到db_file_name_convert和log_file_name_convert兩個參數。
其實,在standby controlfile中,數據文件和archive log文件的記錄名稱還是以“+DATA/ora10g/datafile/***”存在的。
只是每次訪問的時候,在standby中,都會默認通過參數db_file_name_convert和log_file_name_convert進行轉換的。
這樣,我們看到的都是“u01/data/****”。
4. 而回到我們的問題,由于catalog獲取的都是control file中的信息,并沒有db_file_name_convert和log_file_name_convert的轉換,所以,在catalog中,看到的數據文件,即使是通過standby備份的,依然也是以“+DATA/ora10g/datafile/***”名稱存儲的。
而在不連接catalog的時候,通過list bakcup查詢,就會發現,參數db_file_name_convert和log_file_name_convert在其中干預。進而查詢到的結果是“u01/data/****”。
這里我們可以通過實驗,來證明是否是db_file_name_convert和log_file_name_convert影響的結果的輸出
5. 我們取消參數db_file_name_convert和log_file_name_convert的設定,然后在次在本地,通過control file的方式連接RMAN進行查詢,結果如下:
$ 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的干預,顯示的結果就是“+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-166. 通過上面的實驗說明,standby上備份,和主庫是完全相同的。也可以通過standby的備份直接restore到primary數據庫。只是在list backup顯示時,由于db_file_name_convert的干預,結果有差異。
7. 其實這個問題,我們也可以通過查詢v$datafile,來看db_file_name_convert是否影響了數據文件名的輸出:
在db_file_name_convert設置的情況下,查詢standby數據庫
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在沒有設置參數db_file_name_convert的情況下,查詢standby數據庫
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另外有需要云服務器可以了解下創新互聯cdcxhl.cn,海內外云服務器15元起步,三天無理由+7*72小時售后在線,公司持有idc許可證,提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業上云的綜合解決方案,具有“安全穩定、簡單易用、服務可用性高、性價比高”等特點與優勢,專為企業上云打造定制,能夠滿足用戶豐富、多元化的應用場景需求。
網站名稱:ListBakcup在catalog的不同顯示問題-創新互聯
本文地址:http://www.2m8n56k.cn/article30/gjhso.html
成都網站建設公司_創新互聯,為您提供域名注冊、營銷型網站建設、標簽優化、網站營銷、網站內鏈、全網營銷推廣
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:[email protected]。內容未經允許不得轉載,或轉載時需注明來源: 創新互聯