DataGuard学习之部分参数配置
搭建一个10g版本DataGuard环境，难点之一是配置数据库名、角色、归档以及diskgroup等相关的参数。以如下环境为例：
| HostName | Role | instance_name | tnsnames.ora |
| db1 | Primary node1 | db1 | db1,db2,DR1,DR2 |
| db2 | primary node2 | db2 | db1,db2,DR1,DR2 |
| dr1 | Standby Apply node1 | db1 | db1,db2,DR1,DR2 |
| dr2 | Standby node2 | db2 | db1,db2,DR1,DR2 |
总结一些需要根据主机和数据库环境进行自定义的参数。dataguard涉及到的其他参数，类似"log_archive_format”等有固定写法的这里不做解释。
1.DB_NAME
只需注意DataGuard的主备各节点instance使用相同的db_name即可。推荐与service_name一致。
| Primary Site | Standby 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 Site | Standby 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 Site | Standby 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 Site | Standby 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 Site | Standby 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”的属性都是容易习惯性忽略的地方。
