Oracle 11g Dataguard参数详解
注：本文译自《OracleDataGuard11gHandbook》Page78–Page88
就DataGuard（后面都写成DG）来说，我们只关注如下三种参数：
1.独立于数据库角色的参数
2.数据库角色为primary时的参数
3.数据库角色为standby时的参数
虽然DG有着非常多的配置参数，我们实际使用的只有其中很少的部分，而且因为现在许多的DG功能被集成到了代码中，最近的DG版本中很多配置参数已经被弃用了。需要注意的是，为了便于完成数据库的角色转换(Roletransition)，与TNSnames，listener，SRL(StandbyRedolog)文件有关的参数需要在所有数据库中配置。那么现在我们来看看这些参数吧：
一、与角色无关的参数
DB_UNIQUE_NAME 该参数定义了数据库的唯一名称。因为DB_NAME参数需要满足与物理备用数据库(Physicalstandby)名称保持一致，和逻辑备用数据库(logicalstandby)名称不相同的条件，所以在10g中该参数被引入用来区分DG配置中的每一个数据库角色。这个参数需要在所有的数据库中配置，同时需要重启数据库才能生效。如果不配置这个参数，那么默认会使用DB_NAME参数，这就意味着我们不需要关闭生产库来完成备用数据库的配置工作，我们可以在之后进行配置。
db_unique_name='Matrix'
LOG_ARCHIVE_CONFIG 该参数定义了DG配置中可用的DB_UNIQUE_NAME参数值列表。与目标参数（稍后讨论）DB_UNIQUE_NAME的值结合使用时，DG以它们来实现两个数据库之间连接的安全性检查工作。只要不指定SEND和RECEIVE属性，这个参数就是动态的，这两个属性是旧参数REMOTE_ARCHIVE_ENABLE遗留下来的，已经不再需要，因此就不要再使用了。
在实际使用时，你只需要将其他数据库的唯一名称添加到配置就可以了，当前数据库的唯一名会根据场景自动添加；不过为了清晰期间，并且在所有的数据库中保持该参数的一致性，还是会将当前数据库的唯一名称明确的添加上去。对于名称的配置顺序没有要求，该参数在有RAC的环境中是必须要配置的，应该始终使用该参数。
log_archive_config='dg_config=(Matrix,Matrix_DR0)'
CONTROL_FILES 大家都知道这个参数的用途啦（注：当前数据库控制文件的位置），要记住对于备用数据库，它指向的是备用控制文件(StandbyControlFile)的位置。这个控制文件是自动创建的，或者手动创建，取决于你创建备用数据库的方法。（注：自动创建通常发生在使用RMAN功能产生备用数据库过程中，如果你是用的是手工方法，控制文件需要手动的从主库copy过来）
control_files='/Oracle/oradata/Matrix/control01.ctl'
LOG_ARCHIVE_MAX_PROCESSES 提到这个参数是因为它的默认值仍然是2，太小了。在主库中，归档进程负责归档已经写满的在线日志文件（OnlineRedoLog）并作为重做流(RedoSteam)传输到备用数据库来完成间隔处理(Gap)；在备库中，归档进程则是负责归档备库日志文件(StandbyRedoLog)并且将其转发到它的级联备用数据库中。(注：级联备用数据库是指当前备用数据库的下一级备库，即Standby的Standby，从这里可以看出不管什么数据库角色，归档进程的工作的内容都是一样的：1，归档日志文件；2，转发日志文件到Standby)
在主库中，有一个归档进程仅限于对在线日志文件提供服务，无权与备库进行通信，这个特殊的ARCH进程被称为“专用ARCH进程”，而其他归档进程是可以完成这两样功能的。当归档进程向备库发送归档日志文件，就无法协助归档ORL文件了；尽管归档进程的主要指令是“先归档在线日志文件，再处理主备库的间隔，”但是在最坏的情况下，仍然可能只有一个归档进程在进行归档任务。如果没有足够的归档进程，在慢速网络，主备库间出现大的日志间隔的时候，你可能就只有那么一个进程在处理日志文件。这里就会有个非常棘手的问题，那就是如果这个时候你所有的日志文件都已经写满，生产库就停滞了，直到其中的一个文件被归档。在10g中引入了多线程间隔处理特性(MAX_CONNECTIONS)，它允许DG使用多个归档进程向备用数据库发送单个日志文件，这就意味这我们会使用更多的归档日志进程；因此，这个参数至少要设置4，最大值为30。
log_archive_max_processes='4'
备库专用ARCH进程
需要注意的是，备用数据库中也有一个“备库专用ARCH进程”，不过这仅仅意味着在备库中少了一个可以归档SRL文件归档进程而已，在物理备用中，这个专用ARCH进程是没有归档SRL文件功能的。
使用多个归档进程时需要注意一点，虽然增加归档进程可以减少生产环境中断的可能，但是大量的归档进程会增加主备切换(Switchover)的时间，因为这需要唤醒所有的归档进程并使他们退出。我们可以通过在执行切换前将该参数调低来避免这种情况。此外，在11g中引入了新的流式功能(StreamingCapability)，如果正好主备库间的日志间隔非常大，过多的归档进程传输会把整个网络带宽充满。
DB_CREATE_FILE_DEST 虽然这不是DG特有的参数，不过还是需要介绍一下的，因为如果你在备库中使用了ASM，这个参数是要定义的。
db_create_file_dest=+DATA
二、主库角色参数
LOG_ARCHIVE_DEST_n 这个是DG重做日志传输的主要参数，通常都是在主库中起作用，当然也会有例外，比如处理级联备库的场景；该参数也可用来指定由在线重做日志(ORL)或备库重做日志(SRL)产生的归档日志文件的传输目的地，不过随着10gR1版本中闪回恢复区的引入，本地归档的日志文件默认会放在闪回恢复区，所以在这种情况下就不需要再设置本地归档了；我们将会讨论一下本地归档和LOCATION属性，不过应该你已经使用了闪回恢复区，所以不需要再进行LOG_ARCHIVE_DEST_n参数的设置了。
这个参数有17个属性，所有这些属性都是用来设置主库到备库的重做日志传输的；其实你只需要设置其中的7个就可以让日志传输工作正常了；下面我们会先来介绍一下这7个属性并且用一些例子来展示一下它们的用法，然后我们再探讨一下其余的10个属性以及它们的使用场景和使用原因，我们建议不要设置其中的6个属性。
下面是必须的属性：
SERVICE 指定已经创建的备库的TNSNAMES描述符，早期的网络调整就是从这里开始的。(注：这是DG设置中会较早碰到的与网络相关的属性)
SYNC 指定使用同步方法传送重做数据，即客户端事务的提交会发生在LGWR进程收到备库LNS发来的确认信息之后；对于”最大可用模式“和”最大保护模式“，这需要至少一个备库(Standby)。
ASYNC 默认值；如果没有指定日志传输类型的话就会使用异步方式发生重做数据；这是”最大性能模式“下的日志传输方法。
NET_TIMEOUT 指定LGWR进程等待LNS进程响应的时间，如果这期间没有收到响应，则认为备库发生故障(failed)，默认值是30秒，不过10-15可能会是更恰当的值，这取决于你的网络可靠性。不要将这个值设置为10一下，不然你可能会在备库恢复正常后还是无法建立连接，这是因为重新连接备库的操作也会耗费几秒的时间；因此在这之前，我们需要做：
1.停止旧的LNS进程
2.启动新的LNS进程
3.与备库建立连接
4.检测并停止旧的RFS进程
5.启动新的RFS进程
6.选择并打开新的SRL
7.初始化SR头(注：即备库的重做日志数据)
8.响应LNS进程告知已经完成准备工作
所有这些操作完成后，LNS进程才会告诉LGWR进程备库已连接成功；如果这个过程耗费的时间超过了NET_TIMEOUT的值，那么LGWR会再次放弃备库；每次发生日志切换时都会进行这个重新连接动作。
REOPEN 该属性控制主库尝试重新连接已经发生故障的备库的等待时间，默认值是300(5分钟)，这通常是大家抱怨在停止备库后主库不重连的原因。一般来说，测试的时候都会比较快；先shutdownabort备库，观察主库的alert日志看是否与备库断开连接，再启动备库，在主库中切换日志观察是否发生重连，这些操作会在5分钟内完成，所以如果你手法快，DG不会在第一次(或者更多次)日志切换时进行重连。这个属性旨在避免这种情况，即如果备库发生故障以后主库立即切换日志，这个时候的重连很有可能就会失败，因此你可以考虑将这个属性设置成30秒甚至是15秒，这样DG会尽快的完成重连工作。
DB_UNIQUE_NAME 要在参数LOG_ARCHIVE_DEST_n参数中使用这个属性需要同时设置LOG_ARCHIVE_CONFIG参数，否则DG将拒绝连接这个目标库；这个SERVICE目标(远端)名称是你用来连接另一端的数据库(也就是备用数据库)的唯一名称。
你必须同时在两端的数据库中将该唯一名称添加LOG_ARCHIVE_CONFIG参数中。当主库向备库发起连接时，它将会发送自己的数据库唯一名称到备库，同时要求备库返回唯一名称。在备库中将会检查LOG_ARCHIVE_CONFIG参数，以确保主库的唯一名确实存在，如果不存在，连接请求将会被拒绝；如果存在，备库会把自己的唯一名返送回主库的LNS进程，如果返送的值和主库中该属性的值不匹配，连接就会被终止。
和LOG_ARCHIVE_CONFIG参数一样，这个属性在RAC环境下是必须要配置的。
VALID_FOR 这是最后一个必须配置的属性了。尽管你认为不配置这个属性DG也能正常的工作(确实是这样)，不过还是建议你使用它。该参数的主要功能是定义何时使用目标参数LOG_ARCHIVE_DEST_n以及它作用于哪种类型的日志文件。
下面是日志文件的合法值：
1.ONLINE_LOGFILE仅在归档ORL文件时有效
2.STANDBY_LOGFILE仅在归档SRL文件时有效
3.ALL_LOGFILES无论是那种重做日志文件类型都有效
下面是角色的合法值：
1.PRIMARY_ROLE仅在主库中生效
2.STANDBY_ROLE仅在备库中生效
3.ALL_ROLES主备角色都有效
如果这两个参数的答复都是TRUE，VALID_FOR就会允许使用目标参数。(注：这里意思是目标参数会在VALID_FOR的上述两个子项都是TRUE的时候被使用。比如设置为valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)那么如果当前数据库满足是主库并且归档ORL文件的条件，LOG_ARCHIVE_DEST_n内的属性设置就会生效。)有了这个参数，我们就可以预定义DG中所有数据库的所有目标参数了，并其它们仅在VALID_FOR属性都是TRUE的时候生效，这样就没必要再在角色转换时启用和禁用目标了。
那么LOG_ARCHIVE_DEST_n到底会是什么样子呢？最多可以设置9个目标，这就是说我们可以最多拥有9个备库。其实可以使用10个，不过一个是保留用做默认的本地归档目标的，这个我们稍后会讨论。这里我们使用2号参数来添加一个位于曼彻斯特的最高可用的备库。(为了便于显示进行了修改)
log_archive_dest_2='service=Matrix_DR0
SYNCREOPEN=15NET_TIMEOUT=15
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
db_unique_name=Matrix_DR0'
现在再添加一个位于纽瓦克市的备库作为3号参数，它的网络延迟比SYNC长，所以这里以异步模式来传输：
log_archive_dest_3='service=Matrix_DR1
ASYNCREOPEN=15
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
db_unique_name=Matrix_DR1'
当然我们使用了适当的DB_UNIQUE_NAME属性，所以我们还要配置LOG_ARCHIVE_CONFIG参数：
log_archive_config='dg_config=(Matrix,Matrix_DR0,Matrix_DR1)'
下面是可选属性：
AFFIRM 这是使用SYNC方式目标的默认值。要求LNS进程等待RFS进程完成对SRL文件的直接I/O再返回成功消息，还要求是“最高可用”或”最大保护“模式；因为这个属性是基于目标的默认值，所以不需要设置它；尽管在10g中可以为ASYNC方式的目标指定这个属性，不过依然是没有理由的。实际上，它会拖慢LNS进程。在11g中，AFFIRM属性会被ASYNC目标忽略掉。
NOAFFIRM 如果没有特别指定，它会是ASYNC目标的默认值。用于“最大性能”模式；再次声明，因为它是ASYNC的默认值，所以没有必要去指定它；并且如果你对SYNC目标设置NOAFFIRM属性，你的保护模式将违反规定，被标记为“已重新同步”状态。如果这是你唯一的SYNC备库，并且处于最大可用模式，那么你将无法进行零数据丢失的故障转移(Failover)；如果这是你唯一的SYNC目标，并且处于最大保护模式，那么设置AFFIRM属性会让你的主库崩溃。
COMPRESSION 这个属性将启用对备用目标的高级压缩功能。默认情况下，这就意味着任何一个向该目标发送间隔日志的归档进程都会在发送时压缩归档。如果你设置了这个隐藏属性，那么它也会压缩当前发送的重做日志流。举个例子，假如设置这个隐藏参数，我们来对当前的两个目标库来添加COMPRESSION属性：
log_archive_dest_2='service=Matrix_DR0
LGWRSYNCREOPEN=15NET_TIMEOUT=15
COMPRESSION=ENABLE
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
db_unique_name=Matrix_DR0'
log_archive_dest_3='service=Matrix_DR1 LGWRASYNCREOPEN=15 COMPRESSION=ENABLE valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=Matrix_DR1'