物理Standby資料庫的檔案路徑轉換(3)

junsansi發表於2009-05-26
資料庫

前文連結：
物理Standby資料庫的檔案路徑轉換(2)--STANDBY_FILE_MANAGEMENT 引數的值很重要
物理Standby資料庫的檔案路徑轉換(1)--*_FILE_NAME_CONVERT 引數什麼時候生效的呢
==========================================

3、 *_FILE_NAME_CONVERT 能決定一切嗎？

　　通過前面的示例，我們就知道*_file_name_convert並不一定有效，不過，是否除此之外其它情況下，*_file_name_convert引數就能主宰了呢？答案又是否定的。原因請看下列示例：

　　根據JSSPDG建立另一個物理Standby：JSSLDG，然後登陸並檢視相關資訊。

　　首先也是檢視路徑轉換引數的設定：

    JSSLDG> show parameter db_file_

    NAME                                 TYPE        VALUE

    ------------------------------------ ----------- ------------------------------

    db_file_multiblock_read_count        integer     16

    db_file_name_convert                 string      F:\oracle\oradata\jssbook, L:\

                                                     oradata\JSSLDG, L:\oradata\JSS

                                                     LDG, F:\oracle\oradata\jssbook

    db_files                             integer     200

    JSSLDG> select name from v$datafile;

    NAME

    ------------------------------------------------------------------------------------

    L:\ORADATA\JSSPDG\SYSTEM01.DBF

    L:\ORADATA\JSSPDG\UNDOTBS01.DBF

    L:\ORADATA\JSSLDG\SYSAUX01.DBF

    L:\ORADATA\JSSPDG\USERS01.DBF

    L:\ORADATA\JSSPDG\SCOTT01.DBF

　　奇怪啊奇怪，後兩個檔案的路徑可以理解，經常第2例的測試，已知該路徑無法通過convert引數做轉換，但是前面兩個檔案並沒有顯式修改過路徑啊，為什麼convert引數對其也無效呢？仔細回憶JSSLDG的建立過程，由於JSSLDG是通過複製JSSPDG實現，複製時JSSPDG處於REDO應用狀態，難道是這個原因嗎？

　　停止jsspdg物理Standby的REDO應用再複製試試：

    JSSPDG> alter database recover managed standby database cancel;

    Database altered.

　　Jssldg 的再建立就簡單多了，只複製資料檔案日誌檔案就好了，因為初始化引數、金鑰檔案等均不需要做改動，重新執行查詢：

    JSSLDG> select name from v$datafile;

    NAME

    ------------------------------------------------------------------------------------

    L:\ORADATA\JSSPDG\SYSTEM01.DBF

    L:\ORADATA\JSSPDG\UNDOTBS01.DBF

    L:\ORADATA\JSSLDG\SYSAUX01.DBF

    L:\ORADATA\JSSPDG\USERS01.DBF

    L:\ORADATA\JSSPDG\SCOTT01.DBF

　　路徑沒有變化，說明與複製時物理Standby是否處於應用模式無關。此時注意到一個細節問題，由於jsspdg也是剛剛建立並啟動redo應用，而從資料檔案的修改日誌來看，恰恰是修改了system01.dbf和undotbs01.dbf兩個檔案，難道是由於這兩個檔案修改過，Standby 端中的控制檔案路徑就自動做了轉換？測試一下。

　　正常情況下，物理Standby資料庫的控制檔案應該是通過Primary建立，前面為了省事，建立jssldg時也是直接複製的jsspdg的控制檔案，這裡我們嘗試直接通過Primary建立standby控制檔案：

    JSSPRE> alter database create standby controlfile as 'l:\oradata\jssldg\jssldg01.ctl' reuse;

    Database altered.

　　啟動jssldg後重新執行查詢：

    JSSLDG> select name from v$datafile;

    NAME

    ------------------------------------------------------------------------------------

    L:\ORADATA\JSSLDG\SYSTEM01.DBF

    L:\ORADATA\JSSLDG\UNDOTBS01.DBF

    L:\ORADATA\JSSLDG\SYSAUX01.DBF

    L:\ORADATA\JSSLDG\USERS01.DBF

    L:\ORADATA\JSSLDG\SCOTT01.DBF

　　OK ，路徑已經正常顯示。接下來我們再建立一個新的物理Standby環境，以便測試當物理Standby有修改時，是否就會自動轉換自己控制檔案中的檔案路徑。

　　假設新建立的物理Standby叫JSSLDG2(建立步驟省略)，切換回jssldg資料庫，啟動REDO應用，從作業系統中監控一個jssldg資料庫的資料檔案是否有修改，當發現system01.dbf和undotbs01.dbf檔案有修改操作(這兩個檔案太有意思了，要改一塊改。不過想想也正確，應該是巧合，當system表空間資料檔案要操作時，用到了undo表空間，因此才會導致兩個表空間的資料檔案都被修改)，馬上覆制jssldg資料庫的控制檔案到jssldg2資料庫，然後重新啟動jssldg2資料庫，並檢視檔案路徑：

    JSSLDG ２> select name from v$datafile;

    NAME

    ------------------------------------------------------------------------------------

    L:\ORADATA\JSSLDG\SYSTEM01.DBF

    L:\ORADATA\JSSLDG\UNDOTBS01.DBF

    L:\ORADATA\JSSLDG2\SYSAUX01.DBF

    L:\ORADATA\JSSLDG2\USERS01.DBF

    L:\ORADATA\JSSLDG2\SCOTT01.DBF

　　可以看到，修改過的資料檔案的路徑，沒有被convert引數轉換。

　　基於上例，我們又可以得出一個結論，如果物理Standby在執行過程中，修改過檔案(含資料檔案和日誌檔案)，那麼這部分檔案在Standby端控制檔案中的路徑，也會被自動修改成應用*_file_name_convert後的路徑。

　　最後，如果你發現在建立Dataguard環境時，由於Primary資料庫和物理Standby資料庫資料檔案路徑無法保持一致，雖然設定了初始化引數，並且確認引數設定無問題，但Standby端的檔案路徑仍然不對，那不妨對照前面幾個例子，看看是否符合了某些初始化引數無法控制的條件。因為Standby資料庫的路徑轉換是否好使，並不僅僅取決於convert引數是正確配置。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7607759/viewspace-604199/，如需轉載，請註明出處，否則將追究法律責任。

相關文章