主备互相切换用到的参数VALID_FOR、fal_client、fal_server

VALID_FOR


没有写VALID_FOR时，默认VALID_FOR＝(all_logfiles,all_roles) 

VALID_FOR属性由2部分组成:archive_source(online_logfile,standby_logfile,all_logfiles)和database_role(primary_role,standby_role,all_role).
online_logfile: 表示归档联机重做日志
standby_logfile:表示归档备用数据库的重做日志/接受来自主库的重做日志
all_logfiles: online_logfile && standby_logfile

primary_role: 仅当数据库角色为主库时候生效
standby_role: 仅当数据库角色为备库时候生效
all_role: 任意角色均生效


*.log_archive_dest_1='location=/u01/app/oracle/archive_log'
*.log_archive_dest_2='service=DG lgwr async VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DG'

比如主备库都设置如上
主库就会使用位置1来进行归档(而且默认 VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=主库的DB_UNIQUE_NAME)，
使用位置2来进行归档（其实就是通过lgwr async传输到tns中别名为DG，DB_UNIQUE_NAME=DG的备库的/u01/app/oracle/archive_log）

备库只是被动的使用位置1来接受来自主库的归档日志，如alert中会出现的一句话Using STANDBY_ARCHIVE_DEST parameter default value as /u01/app/oracle/archive_log
位置2由于设置为PRIMARY_ROLE而自己是standby则不会生效

一旦发生切换
原来的主库的位置2就不起作用了，原来的备库的位置2就起作用了

如果主备都把位置2设置为ALL_LOGFILES,ALL_ROLES，备库还要给主库发归档日志，那就矛盾了。




*.fal_client、*.fal_server两参数


主备的tns都是如下时
master =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.128.37)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = TDB)
    )
  )


slave =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.128.47)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = TDG)
    )
  )
  
 
 
37的设置(client是自己，server是对方)
*.fal_client='master'
*.fal_server='slave'




47的设置(client是自己，server是对方)
*.fal_client='slave'
*.fal_server='master'

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30126024/viewspace-2128273/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/30126024/viewspace-2128273/