物理Standby数据库的文件路径转换(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参数是正确配置。