2013年（350）
分类： Oracle
2013-04-27 09:46:06
通过前面的示例，我们就知道*_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.DBFOK ，路径已经正常显示。接下来我们再创建一个新的物理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参数是正确配置。
