ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 物理Standby数据库的文件路径转换(3)

物理Standby数据库的文件路径转换(3)

原创 Linux操作系统 作者:junsansi 时间:2009-05-26 13:11:29 0 删除 编辑

前文链接:
物理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 2> 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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
暂无介绍

注册时间:2007-12-21

  • 博文量
    640
  • 访问量
    4128317