DATAGUARD配置参数详细揭示

文档系转载，如有侵权请告知删除

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='standby'

 

 

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(primary,standby)'	*.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=dg_config(primary,standby)' scope=both;

Primary与Standby端的 db_unique_name一致时（虽然db_unique_name可以设置不一致，但是DBA推荐设置不同的db_unique_name，否则可能会触发未知bug）咱也没见过，咱也不知道真假········^_^

primary site	standby site
*.db_unique_name='orcl'	*.db_unique_name='orcl'
*.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_client='DR1'	*.fal_client='DR2'
*.fal_server='DR2'	*.fal_server='DR1'

 

 

 

其中 DR1、DR2分别为主备库的网络服务名 

DB_FILE_NAME_CONVERT
primary与standby上diskgroup的名称(如果db_unique_name不一致，在diskgroup目录下自动创建的目录一般都会不一直，如果没有特别指定数据文件的路径，则默认的路径会不一致，此时需要使用此参数和log_file_name_convert参数)或是数据文件的存放路径不一致的时候，需要定义该参数进行转换，否则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时

数据库仍然只会将表空间和数据文件从数据字典中删除，表空间涉及的物理文件仍需要手工删除。
对于文件系统，我们可以将初始化参数    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 RESETLOG的S应用
在某些情况下，Primary  数据库以  RESETLOG方S式打开之后，也不会影响   Data Guard 的配置，Standby  数据库无须人工参与， 自动应用  OPENRESETLOGS
的操作，继续接收并应用    Primary  数据库  OPEN RESETLOG之S后产生的日志。
当然这是有条件的，并不是所有情况下都能这么智能。我们知道执行 ALTER DATABASE OPEN RESETL语O句GS之后，数据库的 INCARNATION被重置， 也就是此时其 Standby 数据库的 SEQUENCE序号也会从头开始设置。 当然物理 Standby 数据库并不关注这一点， 它只是忠实地紧跟 Primary 数据库的 脚步，一步一步地执行    Primary  数据库曾经执行过的操作，因此当其接收到新的REDO数据时，就会自动应用这部分REDO数据。

图中显示了  Primary  数据库  RESETLOG操S作对  Standby 的影响

Standby数据库状态	Standby数据库操作	解决方案
尚未应用  RESETLOGS 之前的REDO数据	自动应用REDO数据	无需手工介入
应用了RESETLOGS 之前的REDO数据，不过standby数据库启用了FRA	可以回到应用RESETLOGS 之前的状态，不过需要DBA手工介入	手工FLASHBACK DATABASE 到应 应用了  RESETLOG之前的状态，重启REDO应用，已重新接收新的redo数据
应用了RESETLOGS 之前的REDO数据，而standby数据库没有启用FRA	无法进行应用处理	重建屋里Standby是唯一的选择

 

 

 

 

 

 

正常情况下这个逻辑没有问题，不过遇到Primary    执行过 OPEN RESETLOGS之后，又通过备份恢复到    OPEN RESETLOGS之前的状态，视物理Standby
的具体配置（配置方式决定了物理Standby 是否有可能回到OPEN RESETLOGS之前的状态）的不同，情况可能会复杂很多。