注：本文译自《Oracle Data Guard 11g Handbook》 Page 78 – Page 88
就Data Guard（后面都写成DG）来说，我们只关注如下三种参数：
1.独立于数据库角色的参数
2.数据库角色为primary时的参数
3.数据库角色为standby时的参数
虽然DG有着非常多的配置参数，我们实际使用的只有其中很少的部分，而且因为现在许多的DG功能被集成到了代码中，最近的DG版本中很多配置参数已经被弃用了。需要注意的是，为了便于完成数据库的角色转换(Role transition)，与TNS names，listener，SRL(Standby Redo log)文件有关的参数需要在所有数据库中配置。那么现在我们来看看这些参数吧：
一、与角色无关的参数
DB_UNIQUE_NAME 该参数定义了数据库的唯一名称。因为DB_NAME参数需要满足与物理备用数据库(Physical standby)名称保持一致，和逻辑备用数据库(logical standby)名称不相同的条件，所以在10g中该参数被引入用来区分DG配置中的每一个数据库角色。这个参数需要在所有的数据库中配置，同时需要重启数据库才能生效。如果不配置这个参数，那么默认会使用DB_NAME参数，这就意味着我们不需要关闭生产库来完成备用数据库的配置工作，我们可以在之后进行配置。
建议不要使用以下的属性：
LOCATION 在10gR2之前，该属性必须指定一个文件位置用于归档进程存储归档日志文件，并且这在主库(对于ORL文件)和备库(对于SRL文件)确实是正确的。不过随着闪回恢复区和默认本地归档的使用，这个属性已经不再需要设置了。编号为10的目标将自动设置成闪回恢复区。
SQL> ARCHIVE LOG LIST
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 19
Next log sequence to archive 21
Current log sequence 2
如果你正在使用闪回恢复区，并且你想定义一个本地目标，那么应该使用相同的语法：
如果你还是不使用闪回恢复区，也可以使用旧的磁盘路径写法：
注意在如上的两种情况下，DB_UNIQUE_NAME都是指向你在其上定义了目标(注：也就是归档的存放位置)的数据库，而并非远程的备库。在上面的例子中，归档位置目标在Matrix库上，因此如果你要在这里使用DB_UNIQUE_NAME属性，就需要指定Matrix为DB_UNIQUE_NAME的值。
注意：
如果使用闪回恢复区，就不要使用LOCATION属性来指定本地归档位置了。
MANDATORY 这是备库上最危险的属性之一。基本上，它规定ORL文件中的redo信息必须发送到该备库。如果redo信息无法发送到备库，那么主库中包含redo信息的这个ORL文件在成功发送到备库之前将无法被重用(reuse)。试想当备库无法访问并且主库中所有可用的日志文件都被遍历完了，那么生产系统就会停滞。当然，有一个本地目标是MANDATORY的以使文件存放在磁盘上，不过没有必要再设置另一个了。默认情况下，本地归档中的一个目标会被设置成MANDATORY。
注意：
不要设置MANDATORY属性。
MAX_FAILURE 这个属性是所有属性中最遭人误解的一个。人们都倾向与认为这个属性表示LGWR进程在放弃发生故障的备库并继续产生日志之前，重新连接备库的次数。事实并非如此，如果你设置了该属性，实际是定义了LGWR尝试重连有故障的备库时，日志组切换的次数(注：原文写的更加让人容易误解，这里的意思就是切换一次日志，重连一次备库)。举例来说，如果将MAX_FAILURE的值设置成5，那么LGWR将会在它循环切换日志期间对故障备库总共发起5次连接请求，如果切换了5次还是无法连接到故障备库，那么LGWR将放弃重连，之后你要么等手动重新启用它或者等主库重启重新生效该属性。
注意：
不要设置MAX_FAILURE属性。
NOREGISTER 这是我们讨论的LOG_ARCHIVE_DEST_n参数的最后一个属性。默认情况下，DG要求任何发送到备库的redo数据都需要在归档至磁盘的时候完成对备库的注册。对于一个物理备库来说，意味着数据会被注册到备库的控制文件中；而对于逻辑备库来说，它意味着SQL Apply会在元数据中注册日志文件。DG不需要这个属性，它可以用在使用downstream特性的Streams目标库中。
注意：
不要设置NOREGISTER属性。
LOG_ARCHIVE_DEST_STATE_n 这是和LOG_ARCHIVE_DEST_n配套使用的参数。在过去，有两个原因我们需要配置它。一是启用备库中主角色LOG_ARCHIVE_DEST_n参数的预定义，以使得该参数被启用后归档进程可以使用LOG_ARCHIVE_DEST_n来工作；另一个原因是配置一个如前面所述的ALTERNATE目标。第一个原因已经没有作用了(现在使用了VALID_FOR)，并且除非你使用ALTERNATE属性，否则第二个原因也不成立了，因为现在这个参数默认就是ENABLE的了，你不再需要为你的目标库设置它了。
三、备用角色参数
DB_FILE_NAME_CONVERT 在备库中，该参数允许你逻辑上将数据文件从主库迁移到备库上，如果你使用的是基于磁盘的存储结构并且存储路径在两个系统上并不相同，那么就有必要配置它。只有在备库切换为主库这期间，该转换才会执行。一旦进行主备切换或者故障切换到备库，这些值就会被写入到控制文件和数据文件头。通过简单的字符替换就可以实现功能。
LOG_FILE_NAME_CONVERT 它的功能和DB_FILE_NAME_CONVERT参数相同，只不过这里转换的是日志文件，包括ORL文件和任何SRL文件。
在主库的正常工作过程中，归档进程(被指定为ping进程)会轮流查询所有的备库来寻找redo间隔，与此同时处理任何应用进程发来的未解决的间隔请求。当物理备库需要从主库之外的数据库中获得间隔文件时就可以使用FAL技术。举个例子，比如物理备库现在需要进行间隔处理，但是主库无法访问，那么它需要去请求其他的备库来完成间隔处理，为此，你要将FAL_SERVER参数定义为指向主库或者任意备库的TNS标识符列表。如在Matrix_DR0库中加入主库(Matrix)和其他备库(Matrix_DR1)：
STANDBY_FILE_MANAGEMENT 这是本章节讨论的最后一个参数了。这个简单的参数只用于物理备库。该参数设置成AUTO的时候，主库中添加和删除数据文件的同时，备库中也会自动的进行相应的更改。只要备库中顶级目录存在或能够借助于DB_
FILE_NAME_CONVERT参数找到，那么DG将会执行DDL语句在备库中创建数据文件。它甚至会尽可能的创建缺失的子目录。默认情况下，这个参数的值为MANUAL，这意味着备库上的应用进程不会创建新的数据文件，你需要手动创建它们。
参数与属性小结
在了解上面的所有参数和属性之后，你应该对它们的功能和特性有了深刻的理解并且可以正确的配置使用了。
希望你不要对这些感到头疼，因为有一点你或许会感到诧异：如果你使用Data Guard Broker(即使不用Grid Control)，就没必要亲自配置这些参数了，DG Broker会为你做好一切。
END