Dec 1, 2009

网上有一篇介绍dataguard涉及到参数的文章《配置Data Guard涉及到的参数详解》,工作时也从中学到很多。自己总结,格式因为喜好问题难免雷同特提前声明。
搭建一个10g版本DataGuard环境,难点之一是配置数据库名、角色、归档以及diskgroup等相关的参数。以如下环境为例:
HostName Role instance_nametnsnames.ora
db1Primary node1db1db1,db2,DR1,DR2
db2primary node2db2db1,db2,DR1,DR2
dr1Standby Apply node1db1db1,db2,DR1,DR2
dr2Standby node2db2db1,db2,DR1,DR2

总结一些需要根据主机和数据库环境进行自定义的参数。dataguard涉及到的其他参数,类似"log_archive_format”等有固定写法的这里不做解释。
1.DB_NAME
只需注意DataGuard的主备各节点instance使用相同的db_name即可。推荐与service_name一致。
Primary SiteStandby Site
*.DB_NAME='DB'*.DB_NAME='DB'
2.DB_UNIQUE_NAME
Primary与Standby端数据库的唯一名字,设定后不可再更改。
注意:
如果主备db_unique_name不一样,需要与LOG_ARCHIVE_CONFIG配合使用
db_unique_name并未规定需要与数据库service_name一致,可以自定义任意名称。
Primary SiteStandby Site
*.db_unique_name='Primary’*.db_unique_name='Standby’
3.LOG_ARCHIVE_CONFIG
列出主备库上的DB_UNIQUE_NAME 参数。默认情况下,定义该参数保证数据库能够发送或接收redo log。
1>Primary与Standby端的db_unique_name不一致时
Primary SiteStandby Site
*.db_unique_name=Primary*.db_unique_name=Standby
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(Primary,Standby)'*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(Primary,Standby)'
2>Primary与Standby端的db_unique_name一致时
Primary SiteStandby Site
*.db_unique_name=test*.db_unique_name=test
*.LOG_ARCHIVE_CONFIG=''*.LOG_ARCHIVE_CONFIG=''
 
4.LOG_ARCHIVE_DEST_1
本地归档路径。Primary与Standby需要定义各自的online redo log的归档地址,以系统实际的存放路径为准。格式如下:
Primary Site: 
*.LOG_ARCHIVE_DEST_1='LOCATION=/arch/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) '
 
Standby Site:
*.LOG_ARCHIVE_DEST_1='LOCATION=/stdby/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) '
注意:  
1> 当主备两端定义的db_unique_name不一致时,会在LOG_ARCHIVE_DEST_1设置DB_UNIQUE_NAME的值,设置为本地的db_unique_name。以priamry端为例,格式如下:
*.LOG_ARCHIVE_DEST_1='LOCATION=/archivelog/ VALID_FOR=(ALL_LOGFILES,
ALL_ROLES) DB_UNIQUE_NAME=Primary'                        
5.LOG_ARCHIVE_DEST_2
该参数仅当数据库角色为primary时生效,指定primary传输redo log到该参数定义的standby database上。
log_archive_dest_2可以说是dataguard上最重要的参数之一,它定义了redo log的传输方式(sync or async)以及传输目标(即standby apply node),直接决定了dataguard的数据保护级别。
格式如下:
Primary Site: 
*.LOG_ARCHIVE_DEST_2='SERVICE=DR1 lgwr async  VALID_FOR=(ONLINE_LOGFILES, 
PRIMARY_ROLE) '
Standby Site: (switch over后生效) 
*.LOG_ARCHIVE_DEST_2='SERVICE=db1 lgwr async  VALID_FOR=(ONLINE_LOGFILES, 
PRIMARY_ROLE) ' 
注意:  
1> LOG_ARCHIVE_DEST_2参数里定义的service值,比如DR1,是tnsnames.ora文件里定义的Oracle Net名称。
2> 有时会在LOG_ARCHIVE_DEST_2定义DB_UNIQUE_NAME的值,当前节点设置的均为另一端数据库的db_unique_name。以primary端为例,格式如下:
*.LOG_ARCHIVE_DEST_2='SERVICE=DR1 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,
PRIMARY_ROLE) DB_UNIQUE_NAME=Standby'                       
 
6.LOG_ARCHIVE_DEST_3
该参数仅当数据库角色为standby时生效,定义standby database归档从primary database传过来的redo log的路径。
oracle10g官方文档只是在create logical standby时解释了log_archive_dest_3这个参数,搭建physical standby时并没有做任何介绍。
Primary Site: 
*.LOG_ARCHIVE_DEST_3='LOCATION=/archivelog/standbylog/  VALID_FOR=
(STANDBY_LOGFILES,STANDBY_ROLE) '
Standby Site: 
*.LOG_ARCHIVE_DEST_3='LOCATION=/arch/arch3/  VALID_FOR=(STANDBY_LOGFILES, 
STANDBY_ROLE) '
注意:  
LOCATION定义的路径以本节点能读写的实际路径为准。
7.LOG_ARCHIVE_DEST_STATE_n
设置为ENABLE,激活log_archive_dest_n定义的属性。
8.FAL_SERVER and FAL_CLIENT
FAL是Fetch Archive Log的简写,它是dataguard主备之间GAP的处理机制。
Primary上不会有GAP,所以fal_server和fal_client也是只在standby上生效的参数,当然为了switch over的需要同样会在primary端进行预设置。
FAL参数定义的数据库名同样取自本地tnsnames.ora里配置的Oracle Net Service Name.
Primary SiteStandby Site
*.fal_server='DR1',’DR2’ *.fal_server='db1',’db2’
*.fal_client='db1' *.fal_client='DR1'

9.DB_FILE_NAME_CONVERT
primary与standby上diskgroup的名称或是数据文件的存放路径不一致的时候,需要定义该参数进行转换,否则standby apply后无法创建与primary一致的数据文件并报错。
格式如下:
Primary Site: 
*.db_file_name_convert='+DATAGRP/db/datafile/','+DG1/db/datafile/'
Standby Site: 
*.db_file_name_convert='+DG1/db/datafile/','+DATAGRP/db/datafile/'        
1> +DG1/db/datafile/是primary dastabase上存放datafile的路径
2> +DATAGRP/db/datafile/是standby上存放datafile的路径
注意:
1>primary上的该参数仅在主备switch over后生效
2>注意格式应保持一致,比如"*.db_file_name_convert='+DG1/db/datafile','+DATAGRP/db/datafile/' ”,路径少了一个"/”,将导致standby apply失败。
3>primary上执行create tablespace等add datafile操作时,无须自定义datafile的全路径名称,由数据库自动创建datafile即可。
10.LOG_FILE_NAME_CONVERT
同DB_FILE_NAME_CONVERT类似,定义主备log文件的存放路径转换。
 
--最后总结
整理的过程中,发现一些参数涉及到很多细节问题。特别是LOG_ARCHIVE_DEST_2参数直接关系到redo log的传输机制,而其中类似" LGWR ASYNC”和"VALID_FOR ”的属性都是容易习惯性忽略的地方。
 
from :http://fbirdzp.blogbus.com/tag/oracle,dataguard,%E5%8F%82%E6%95%B0,LOG_ARCHIVE_DEST_2/