DB_NAME
只需注意DataGuard的主备各节点instance使用相同的db_name即可。推荐与service_name一致。
| Primary Site |
Standby Site |
| *.DB_NAME='DB' | *.DB_NAME='DB’ |
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='Standb |
LOG_ARCHIVE_CONFIG
列出主备库上的DB_UNIQUE_NAME 参数。默认情况下，定义该参数能确保主备库数据库能够互相识别对方
Primary与Standby端的db_unique_name不一致时
| Primary Site | Standby Site |
| *.db_unique_name=Primary |
*.db_unique_name=Standby |
| *.LOG_ARCHIVE_CONFIG='DG_CONFIG=(Standby,Primary )' | *.LOG_ARCHIVE_CONFIG='DG_CONFIG=(Primary,Standby)' |
如在主备库db_unique_name不一致的情况下未配置 LOG_ARCHIVE_CONFIG则会出现如下报错
ORA-16057: DGID from server not in Data Guard configuration
原因:主库没有设置参数log_archive_config
解决方法*.log_archive_config='dg_config=( Primary , Standby )'
alter system set log_archive_config='dg_config=( Standby ,Primary )' scope=both;
Primary与Standby端的db_unique_name一致时
| Primary Site | Standby Site |
| *.db_unique_name=test | *.db_unique_name=test |
| *.LOG_ARCHIVE_CONFIG='' | *.LOG_ARCHIVE_CONFIG=' |
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) '
注意：
在LOG_ARCHIVE_DEST_n设置DB_UNIQUE_NAME表示该参数在 DB_UNIQUE_NAME指定的数据库上生效 ，设置为本地的db_unique_name。以priamry端为例，格式如下：
*.LOG_ARCHIVE_DEST_1='LOCATION=/archivelog/ VALID_FOR=(ALL_LOGFILES,
ALL_ROLES) DB_UNIQUE_NAME=Primary'
这样配置的意义为： 在数据库 Primary 上log_archive_dest_1对主备库上的联机日志都有效，这里的 db_unique_name可以 省略
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=DR2 lgwr async VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) '
Standby Site: (switch over后生效)
*.LOG_ARCHIVE_DEST_2='SERVICE=DR1 lgwr async VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) '
注意：
LOG_ARCHIVE_DEST_2参数里定义的service值，比如DR1，是tnsnames.ora文件里定义的Oracle Net名称。
有时会在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'
这个参数的意义为： 在数据库DR1上log_archive_dest_2对主库上的联机日志都有效
关于valid_for参数，有如下解释：
The redo_log_type keyword identifies the destination as valid for archiving to one of the following:
ONLINE_LOGFILE:This destination is valid only when archiving online redo log files.
STANDBY_LOGFILE:This destination is valid only when archiving standby redo log files.
ALL_LOGFILES:This destination is valid when archiving either online redo log files or standby redo log files.
The database_role keyword identifies the role in which this destination is valid for archiving:
PRIMARY_ROLE:This destination is valid only when the database is running in the primary role.
STANDBY_ROLE:This destination is valid only when the database is running in the standby role.
ALL_ROLES:This destination is valid when the database is running in either the primary or the standby role.
LOG_ARCHIVE_DEST_3
该参数仅当数据库角色为standby时生效，定义primary database的日志写到standby database的standby redo log中。
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定义的路径以本节点能读写的实际路径为准。
LOG_ARCHIVE_DEST_STATE_n
设置为ENABLE，激活log_archive_dest_n定义的属性。
FAL_SERVER and FAL_CLIENT
当Primary Database的某些日志没有成功发送到Standby Database， 这时候发生饿了归档裂缝（Archive Gap）。
FAL是Fetch Archive Log的简写，它是dataguard主备之间GAP的处理机制。
当Primary Database的某些日志没有成功发送到Standby Database， 这时候发生饿了归档裂缝（Archive Gap）。
Primary上不会有GAP，所以fal_server和fal_client也是只在standby上生效的参数，当然为了switch over的需要同样会在primary端进行预设置。
缺失的这些日志就是裂缝（Gap）。 Data Guard能够自动检测，解决归档裂缝，不需要DBA的介入。这需要配置FAL_CLIENT， FAL_SERVER 这两个参数（FAL: Fetch Archive Log）。
从FAL 这个名字可以看出，这个过程是Standby Database主动发起的“取”日志的过程，Standby Database 就是FAL_CLIENT. 它是从FAL_SERVER中取这些Gap， 10g中，这个FAL_SERVER可以是Primary Database， 也可以是其他的Standby Database。
如：FAL_SERVER='PR1,ST1,ST2';
FAL_CLIENT和FAL_SERVER两个参数都是Oracle Net Name。 FAL_CLIENT 通过网络向FAL_SERVER发送请求，FAL_SERVER通过网络向FAL_CLIENT发送缺失的日志。 但是这两个连接不一定是一个连接。 因此FAL_CLIENT向FAL_SERVER发送请求时，会携带FAL_CLIENT参数值，用来告诉FAL_SERVER应该向哪里发送缺少的日志。 这个参数值也是一个Oracle Net Name，这个Name是在FAL_SERVER上定义的，用来指向FAL_CLIENT.
FAL参数定义的数据库名同样取自本地tnsnames.ora里配置的Oracle Net Service Name.
| Primary Site | Standby Site |
| *.fal_server='DR2’ | *.fal_server=' DR1 ’ |
| *.fal_client='DR1' | *.fal_client=' DR2' |
其中DR1、DR2分别为主备库的网络服务名
DB_FILE_NAME_CONVERT
primary与standby上diskgroup的名称或是数据文件的存放路径不一致的时候，需要定义该参数进行转换，否则standby apply后无法创建与primary一致的数据文件并报错。
db_file_name_convert 主数据库和备用数据库的数据文件转换目录对映（如果两数据库的目录结构不一样），如果有多个对映，逐一指明对映关系。
格式：
*.db_file_name_convert=主数据库数据文件目录，备用数据库数据文件目录
例如：
Primary Site:
*.db_file_name_convert='+DATAGRP/db/datafile/','+DG1/db/datafile/'
或者*.db_file_name_convert='/u01/app/oradata/standby','/u01/app/oradata/primary'
Standby Site:
*.db_file_name_convert='+DG1/db/datafile/','+DATAGRP/db/datafile/'
或者*.db_file_name_convert='/u01/app/oradata/ primary ','/u01/app/oradata/ standby '
其中+DG1/db/datafile/是primary dastabase上存放datafile的路径，+DATAGRP/db/datafile/是standby上存放datafile的路径
多对多映射设定
*.db_file_name_convert='/opt/oracle/oraInventory/oradata/oracle',
'/opt/oracle/oraInventory/oradata/standby','/home/ldai/testdb',
'/home/ldai/testdb/standby'
注意: primary上的该参数仅在主备switch over后生效,格式应保持一致，比如"*.db_file_name_convert='+DG1/db/datafile','+DATAGRP/db/datafile/' ”，路径少了一个"/”，将导致standby apply失败。这个参数仅对standby数据库有效
primary上执行create tablespace等add datafile操作时，无须自定义datafile的全路径名称，由数据库自动创建datafile即可。
LOG_FILE_NAME_CONVERT
同DB_FILE_NAME_CONVERT类似，定义主备log文件的存放路径转换。
STANDBY_FILE_MANAGEMENT
初始化参数STANDBY_FILE_MANAGEMENT作用于standby数据库 ，用来控制是否自动将Primary数据库增加表空间或数据文件的改动，传播到物理Standby数据库。该参数有两个值：
AUTO：如果该参数值设置为AUTO，则Primary数据库执行的表空间创建操作也会被传播到物理Standby数据库上执行。
MANUAL：如果设置为MANUAL或未设置任何值（默认值是MANUAL），需要手工复制新创建的数据文件到物理Standby服务器。
注意：STANDBY_FILE_MANAGEMENT参数特指Primary数据库端的表空间或数据文件创建，如果数据文件是从其他数据库复制而来（比如通过TTS传输表空间），则不管STANDBY_FILE_MANAGEMENT参数值如何设置，都必须同时手工复制到Standby数据库，并重建物理Standby数据库的控制文件。
在Primary数据库端删除表空间时，会影响到物理Standby端数据库的数据文件和表空间，初始化参数STANDBY_FILE_MANAGEMENT的属性值设置决定了该事件是否需要DBA介入。
当STANDBY_FILE_MANAGEMENT设置为AUTO。
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
System altered.
在Primary数据库端执行删除表空间的操作：
SQL> DROP TABLESPACE TEST INCLUDING CONTENTS AND DATAFILES;
Tablespace dropped.
INCLUDING DATAFILES子句，在删除表空间时Oracle也将自动删除对应的物理文件。
将初始化参数STANDBY_FILE_MANAGMENT设置为AUTO，对于表空间和数据文件的操作无须DBA手工干预，物理Standby能很好地进行处理。
当STANDBY_FILE_MANAGEMENT参数设置为MANUAL时，即使DBA在Primary数据库端执行删除操作时加上了INCLUDING DATAFILES子句，Standby数据库仍然只会将表空间和数据文件从数据字典中删除，表空间涉及的物理文件仍需要手工删除。
对于文件系统，我们可以将初始化参数STANDBY_FILE_MANAGMENT设置为AUTO，但是对于裸设备，只能将该参数设置为MANUAL。
在Primary数据库端执行数据文件重命名操作：
如果Primary数据库重命名了一个或多个数据文件，该项修改并不会自动传播到Standby数据库。 就算设置了初始化参数STANDBY_FILE_MANAGEMENT等于AUTO也不行，要让Standby的数据文件与Primary保持一致，只能手工操作。
1、alter tablespace/datafile offline;
2、使用操作系统命令来拷贝
3、alter databaser rename datafile '....' to '...'
4、alter tablespace/datafile online;
5、确认STANDBY DB中所有归档已经apply
6、alter database recover managed standby database cancel停止redo apply
7、拷贝并重命名数据文件
8、alter database rename file '...' to '....';
9、alter databas recover managed standby database disconnect from session.
添加或删除Redologs文件
数据库调优时极有可能会涉及重置日志文件大小或增加删除日志组等操作，如果STANDBY_FILE_MANAGEMENT参数值设置为AUTO的话，这种操作也会被传播到物理Standby数据库。不过在一般情况下，你可以不管STANDBY_FILE_MANAGEMENT参数的设置，因为无论Primary端对日志组或日志文件的操作是否传播到物理Standby数据库，也不会影响到物理Standby数据库的运行，不过如果你不注意其中的关系，造成的影响可能会很深远。
通常建议当你在Primary数据库增加或删除Online Redologs时，一定记得手工同步相关物理Standby数据库中相关的设置，同时也要考虑好Standby Redologs与Online Redologs之间的关系，即保证Standby Redologs比Online Redologs要至少多一组。
注意的就是在Standby数据库端操作前务必将STANDBY_FILE_MANAGEMENT设置为MANUAL，如果物理Standby数据库的日志文件与Primary数据库路径不同的话，应该通过初始化参数LOG_FILE_NAME_CONVERT的设置，让其自动进行转换。
Standby redo log组数公式>=(每个instance日志组个数+1)*instance个数，例如
rac 2台机器 每台3组 则 standy 需8组，并且创建时要为每个实例建4组。一般来说，逻辑备库需要更多的redo组数，这是由于逻辑备库有自身的redo日志，而这些redo日志优先归档，故同等条件下逻辑备库的归档速度比物理备库的慢。
跨OPEN RESETLOGS的应用
在某些情况下，Primary数据库以RESETLOGS方式打开之后，也不会影响Data Guard的配置，Standby数据库无须人工参与，自动应用OPEN RESETLOGS的操作，继续接收并应用Primary数据库OPEN RESETLOGS之后产生的日志。
当然这是有条件的，并不是所有情况下都能这么智能。我们知道执行ALTER DATABASE OPEN RESETLOGS语句之后，数据库的INCARNATION被重置，也就是此时其Standby数据库的SEQUENCE序号也会从头开始设置。当然物理Standby数据库并不关注这一点，它只是忠实地紧跟Primary数据库的脚步，一步一步地执行Primary数据库曾经执行过的操作，因此当其接收到新的REDO数据时，就会自动应用这部分REDO数据。
图中显示了Primary数据库RESETLOGS操作对Standby的影响
| Standby 数据库状态 | Standby 数据库操作 |
解决方案 |
| 尚未应用RESETLOGS 之前的 REDO 数据 | 自动应用REDO 数据 | 无须手工介入 |
| 应用了RESETLOGS 之后的 REDO 数据，不过 Standby 数据库启用了 FRA | 可以回到应用RESETLOGS 之前的状态，不过需要 DBA 手工介入 | 手工FLASHBACK DATABASE 到应用 RESETLOGS 日志之前的状态 重启REDO 应用，以重新接收新的 REDO 数据 |
| 应用了RESETLOGS 之后的 REDO 数据，而且没有配置 FRA | 无法进行应用处理 | 重建物理Standby 是唯一的选择 |
正常情况下这个逻辑没有问题，不过遇到Primary执行过OPEN RESETLOGS之后，又通过备份恢复到OPEN RESETLOGS之前的状态，视物理Standby的具体配置（配置方式决定了物理Standby是否有可能回到OPEN RESETLOGS之前的状态）的不同，情况可能会复杂很多。
参考至：http://java-beginner-liyun.iteye.com/blog/monthblog/2010-07?show_full=true
http://www.linuxidc.com/Linux/2011-09/42721p3.htm
http://www.cnblogs.com/sopost/archive/2010/01/30/2190114.html
http://epub.itpub.net/6/5.htm
http://wenku.baidu.com/view/deec7e29cfc789eb172dc8f5.html
本文原创，转载请注明出处、作者
如有错误，欢迎指正