Data Guard相关参数

Data Guard存在三类参数：独立于数据库角色的参数、用户主库的参数、用于备库的参数。

独立于数据库角色的参数

1.DB_UNIQUE_NAME

参数是数据库定义唯一名称。因为DB_NAME参数对于物理数据库而言必须相同,对于逻辑库而言必须不同,所以10g引入该参数来确定Data Guard配置中的每个数据库.需要在所有数据库上进行设置,但需要重启数据库，默认使用DB_NAME。

2.LOG_ARCHIVE_CONFIG

参数定义Data Guard配置的有效DB_UNIQUE_NAME参数列表。与目标参数的DB_UNIQUE_NAME特性结合使用时。它为Data Guard提供安全性检查点：两个数据库之间的连接是允许的。只要不使用SEND和RECEIVE特性，该参数就是动态的。SEND和RECEIVE特性是旧参数REMOTE_ARCHIVE_ENABLE的遗留物，已经废弃，所以不要再使用它们。

3.LOG_ARCHIVE_MAX_PROCESSES

参数默认为2，而这是不够的。主数据库上的归档进程负责归档写满的redo文件并处理到备用数据库的重做流的间隔。在备用数据库上，它们负责归档standby redo文件，并归档日志转发到级联备用数据库。

在主数据库，一个归档进程仅限为ORL文件提供服务，根本无权与备用数据库通信。这个特殊ARCH进程称为“专用ARCH进程”。但其它进程可同时执行这两项功能。当一个归档进程向备用数据库发送归档日志时，就不能协助归档ORL文件。尽管归档进程的基本指令是“总是先归档联机日志文件，然后才处理间隔”，但在最糟情况下，仍可能仅有那一个归档进程在归档联机日志文件。如果没有足量进程，当慢速网络上存在较大间隔时，可能仅有一个归档进程在处理ORL文件。我们注意到一个棘手问题：如果ORL文件同时全部写满，生产将停止，直至其中一个得到归档为止。Oracle  Database 10g引入的多线程间隔处理特性MAX_CONNECTIONS允许DataGuard使用多个归档进程向备用发送单个日志文件。该参数的最大值为30。

备用专用ARCH进程

一定要注意，虽然物理备用数据库有“专用ARCH”进程，但这仅意味着备用数据库上少了一个可用于归档SRL文件的ARCH进程。在物理备库上，也不允许专用ARCH进程归档备库重做日志文件。

使用多个归档进程时要注意一点：尽管需要多个进程来防止生产系统中断，但大量归档进程会降低切换速度，因为需要唤醒所有这些进程并要求其退出。可通过在启动切换前缩小该参数来避免这种情况。此外，Oracle Database 11个具有新的流功能，如果恰逢一个非常大的重做间隔，太多的归档进程会填满网络。

4.DB_CREATE_FILE_DEST

这不是Data Guard特有的参数，但值得在这里列出，因为如果正在使用ASM，将需要在备用数据库定义它。

主库角色参数

1.LOG_ARCHIVE_DEST_n这是Data Guard重做传输的主要参数，通常在主库上发挥作用。当然有一些例外，这些例外主要发生在处理机连备用目标的情形。该参数还能用于指定ORL文件或者SRL文件的归档日志应该去往哪里。该参数有17个特性，可在设置到备用数据库的重做传输时配置所有这些特性。使用Data Guard将重做数据正确传输到备库，只需设置其中7个特性。

SERVICE：指定创建的指向备库的TNS描述符。

SYNC：指定准备使用同步方法传输重做数据，这意味着LGWR进程将等待来自LNS的确认消息，然后才告知客户端事务已经提交。对于最高可用性和最大保护模式而言，至少有一个备用目标需要该配置。

ASYNC：这是默认传输方法，如果不指定传输类型，将得到异步重做传输。这是最高性能重做传输方法。

NET_TIMEOUT：指定LGWR进程等待LNS进程做出相应的秒数。如果超过指定时间，将因故障放弃备用。默认值是30秒，但根据网络的可靠性，10~15秒会是更恰当的值，具体取决于网络的可靠性。不要设置为低于10秒，那样在备用数据库恢复后，将得到重连失败的情形，因为完成所有重连需要耗费几秒的时间。在重新连接时，需要执行下列步骤：

• 停止旧LNS进程。
• 启动新LNS进程。
• 连接到备用数据库。
• 检测和停止旧RFS进程。
• 启动新RFS进程。
• 选择并打开新SRL。
• 初始化SR头
• 向LNS发回响应：一切已经准备就绪。

完成所有这些步骤以后，LNS进程才告诉LGWR准备开始。如果该过程耗时超过该参数的值，LGWR将再次放弃备用，并在每次切换日志时全部重来一次。

REOPEN：控制Data Guard允许主数据库尝试重连故障备用数据库前等待的时间。默认值是300秒，这通常是有人抱怨在中止备库后DataGuard不重连的缘故。一般来说，测试模式下速度快，所以操作时针对备用执行SHUTDOWN ABORT，观察数据库的告警日志看它是否与备用断开连接，重启备用数据库，然后再主数据库上切换日志，以便看到Data Guard重连。所有这些在300秒完成。因此如果切换速度过快，Data Guard不会在第一次日志切换时重连。该特性旨在避免一下情形：如果在备库目标失败后立即切换日志，可能阻止连接尝试。可考虑将特性缩小为30秒甚至15秒，这样Data Guard会尽快重连。

DB_UNIQUE_NAME：要在LOG_ARCHIVE_DEST_n参数中使用该特性，还需要设置LOG_ARCHIVE_CONFIG参数；否则Data Guard将拒绝连接到备库。这个用作service目标的名称是为连接到另一端的数据库指定的唯一名称。

还必须将这个唯一名称输入两端数据库的LOG_ARCHIVE_CONFIG参数中。当主库连接备库时，会向备库发送自己的唯一数据库名，同时要备库返回唯一名称。备库将检查配置参数LOG_ARCHIVE_CONFIG，确保主数据库的唯一名称存在。如果不存在，将拒绝连接。如果存在，备用数据库会将自己的唯一名称发回到主LNS进程。如果返回值于该特性中指定的值不匹配，连接将终止。

VALID_FOR：这是最后一个必须的特性。该特性的主要作用是定义何时使用LOG_ARCHIVE_DEST_n目标参数，以及应在哪类重做日志文件上允许。

下面列出日志文件的合法值：

• ONLINE_LOGFILE  仅归档ORL文件时有效
• STANDBY_LOGFILE 仅规定SRL文件时有效
• ALL_LOGFILEs 无论对哪种日志文件都有效

下面列出角色的合法值：

• PRIMARY_ROLE 仅对担当主角色的数据库有效
• STANDBY_ROLE 仅对担当备用角色的数据库有效
• ALL_ROLES 无论何种数据库角色都有效

如果两个参数的回答都是TRUE，VALID_FOR将允许使用目标参数。有了该特性，可预定义Data Guard配置中所有数据库的所有目标参数，并且仅当VALID_FOR是TRUE时才能使用他们。在转会角色时没有更多启用或禁用目标。

备库角色参数

1.DB_FILE_NAME_CONVERT该参数允许在逻辑上将数据文件从主库位置移到备用数据库位置。如果两个磁盘结构和布局不同，该操作是必需的。

2.LOG_FILE_NAME_CONVERT该参数与DB_FILE_NAME_CONVERT功能相同，作用于ORL。

3.FAL_SERVER  FAL即Fetch Archive Log功能,它只用于物理备库；使用该进程，物理备库可在发现问题时，从主数据库获取缺少的归档日志文件，这有时称作反应性间隔处理。

3.FAL_CLIENTFAL客户端是间隔请求数据库的TNS名称，间隔请求接收者为FAL_SERVER定义的TNS名称。该参数只对物理备库有效。

4.STANDBY_FILE_MANAGEMENT该简单参数仅用于物理备用数据库。如果将参赛设置为AUTO，每当在主数据库上添加或删除数据文件时，会自动在备用数据库上执行响应更改。只要备用数据库中存在顶级目录，或可利用DB_FILE_NAME_CONVERT参数找到，Data Guard就会在备库上执行DDL来创建数据文件。该参数默认为MANUAL，这意味着物理备库上的应用进程不会自动创建新数据文件。