这篇文章主要介绍了 Oracle 11g Dataguard 参数详解, 包含了独立参数, 主库参数, 备库参数的详细说明, 需要的朋友可以参考下.
注: 本文译自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 参数, 这就意味着我们不需要关闭生产库来完成备用数据库的配置工作, 我们可以在之后进行配置.
代码如下:
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 大家都知道这个参数的用途啦 (注: 当前数据库控制文件的位置), 要记住对于备用数据库, 它指向的是备用控制文件(Standby Control File) 的位置. 这个控制文件是自动创建的, 或者手动创建, 取决于你创建备用数据库的方法.(注: 自动创建通常发生在使用 RMAN 功能产生备用数据库过程中, 如果你是用的是手工方法, 控制文件需要手动的从主库 copy 过来)
代码如下:
control_files='/Oracle/oradata/Matrix/control01.ctl'
LOG_ARCHIVE_MAX_PROCESSES 提到这个参数是因为它的默认值仍然是 2, 太小了. 在主库中, 归档进程负责归档已经写满的在线日志文件 (Online Redo Log) 并作为重做流 (Redo Steam) 传输到备用数据库来完成间隔处理 (Gap); 在备库中, 归档进程则是负责归档备库日志文件(Standby Redo Log) 并且将其转发到它的级联备用数据库中.(注: 级联备用数据库是指当前备用数据库的下一级备库, 即 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 中引入了新的流式功能(Streaming Capability), 如果正好主备库间的日志间隔非常大, 过多的归档进程传输会把整个网络带宽充满.
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 分钟), 这通常是大家抱怨在停止备库后主库不重连的原因. 一般来说, 测试的时候都会比较快; 先 shutdown abort 备库, 观察主库的 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
- SYNC REOPEN=15 NET_TIMEOUT=15
- valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
- db_unique_name=Matrix_DR0'
现在再添加一个位于纽瓦克市的备库作为 3 号参数, 它的网络延迟比 SYNC 长, 所以这里以异步模式来传输:
代码如下:
- log_archive_dest_3='service=Matrix_DR1
- ASYNC REOPEN=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
- LGWR SYNC REOPEN=15 NET_TIMEOUT=15
- COMPRESSION=ENABLE
- valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
- db_unique_name=Matrix_DR0'log_archive_dest_3='service=Matrix_DR1
- LGWR ASYNC REOPEN=15
- COMPRESSION=ENABLE
- valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
- db_unique_name=Matrix_DR1'
Matrix_DR0 目标库仅在 ARCH 进程发送用于间隔处理的归档日志的时候才会使用压缩功能(并非用于同步 SYNC 的归档日志), 而 Matrix_DR1 库自始至终都会压缩重做日志. 这里说明日志并不会在磁盘也保持压缩状态, 因为只会在传输过程中压缩日志, 所以这些传输到备库的数据会被解压缩, 然后再写入到 SRL 文件中.
MAX_CONNECTIONS 该属性在 10gR2 中被引入, 它允许你指定用于备库间隔处理的归档进程的数量, 在 11g 中已经弃用. 不过如果你的版本是 10g, 你可以为它指定值 1-5(默认值 1); 如果你设置的值大于 1 时, 每当备库需要进行间隔处理的时候, 主库将分配对应数量的归档进程用来发送归档日志文件, 这些文件会被分片给这些归档进程, 同时在网络中以并行流的形式传送, 并在传送到备库时重新装配.
代码如下:
- log_archive_dest_2='service=Matrix_DR0
- LGWR SYNC REOPEN=15 NET_TIMEOUT=15
- MAX_CONNECTIONS=5
- valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
- db_unique_name=Matrix_DR0'
现在当 Matrix_DR0 库与主库断开连接的时候, 主库的间隔处理进程将会对每一个确实的归档日志文件使用多个重做流.
注意:
不要在 11g 数据库中使用? MAX_CONNECTIONS 属性, 这会降低日志传输的性能.
DELAY 这个属性并不是像大多数想象的那样延迟重做数据的传输, 它只是用来指示备库目标的日志应用进程在 DELAY 属性设置的时间 (秒) 后应用重做数据. 有了闪回数据库, 这个属性几乎被弃用, 尤其在自从我们建议在主备库中一直启用闪回数据库功能后. 如果你倾向于完成一些闪回数据库无法处理的任务量, 则可能需要设置这个延迟时间. 第 8 章将讨论闪回数据库和 Data Guard.
ALTERNATE 替代 (ALTERNATE) 目标最初的目的是, 当正在归档 ORL 日志文件的磁盘空间已满时, 保持数据库的持续运行. 使用替代目标, 你可以将归档日志文件重定向到一个备用磁盘中. 有了闪回恢复区(自动管理空间), 这个问题基本上消失了.
如果你有多个指向备库的网络路径, 也可以为远程备用目标使用该属性. 显然, 你会在 RAC 环境中使用多个备库网络路径, 但是这并不是 ALTERNATE 属性设计的初衷. 对于有着多网卡的单实例或者 RAC 的环境, 在备库的 TNS 描述符中使用 connect-time failover 会更简便.(注: 参见 connect-time failover http://docs.oracle.com/cd/E11882_01/network.112/e10835/tnsnames.htm#NETRF263 )
建议不要使用以下的属性:
LOCATION 在 10gR2 之前, 该属性必须指定一个文件位置用于归档进程存储归档日志文件, 并且这在主库 (对于 ORL 文件) 和备库 (对于 SRL 文件) 确实是正确的. 不过随着闪回恢复区和默认本地归档的使用, 这个属性已经不再需要设置了. 编号为 10 的目标将自动设置成闪回恢复区.
代码如下:
- SQL> SELECT DESTINATION FROM V$ARCHIVE_DEST WHERE DEST_ID=10;
- USE_DB_RECOVERY_FILE_DEST
- 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
如果你正在使用闪回恢复区, 并且你想定义一个本地目标, 那么应该使用相同的语法:
代码如下:
- log_archive_dest_1='location=USE_DB_RECOVERY_FILE_DEST
- valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
- db_unique_name=Matrix'
如果你还是不使用闪回恢复区, 也可以使用旧的磁盘路径写法:
代码如下:
- log_archive_dest_1='location=/u03/oradata/Matrix/arch/
- valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
- db_unique_name=Matrix'
注意在如上的两种情况下, 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 的了, 你不再需要为你的目标库设置它了.
代码如下:
log_archive_dest_state_1=enable
三, 备用角色参数
DB_FILE_NAME_CONVERT 在备库中, 该参数允许你逻辑上将数据文件从主库迁移到备库上, 如果你使用的是基于磁盘的存储结构并且存储路径在两个系统上并不相同, 那么就有必要配置它. 只有在备库切换为主库这期间, 该转换才会执行. 一旦进行主备切换或者故障切换到备库, 这些值就会被写入到控制文件和数据文件头. 通过简单的字符替换就可以实现功能.
代码如下:
db_file_name_convert='/Matrix/','/Matrix_DR0/'
上面的命令会将如下数据文件名:
代码如下:
'/u03/oradata/Matrix/sysaux.dbf'
转换为:
代码如下:
'/u03/oradata/Matrix_DR0/sysaux.dbf'
同理, 如下配置会将数据文件指向到 + RECOVERY 磁盘组中而不是 + DATA;
代码如下:
db_file_name_convert='+DATA','+RECOVERY'
路径的其他部分将保持相同, 在本例中, 使用了 ASM 来创建备库, 你不需要定义这个参数了.
LOG_FILE_NAME_CONVERT 它的功能和 DB_FILE_NAME_CONVERT 参数相同, 只不过这里转换的是日志文件, 包括 ORL 文件和任何 SRL 文件.
代码如下:
log_file_name_convert='/Matrix/','/Matrix_DR0/'
FAL_SERVER FAL(Fetch Archive Log)功能相比 9iR1 时的 DG 已经有了很大的进步. 它只用于物理备库, 配置它能够使得物理备库在发现问题时, 从 DG 配置中的一个数据库 (主库或备库) 中获取缺失的归档日志文件, 有时我们又成它为被动间隔处理 (reactive gap resolution), 不过 FAL 技术在之前的三个版本中得到了极大的增强以至于现在几乎不需要再定义 FAL 参数了. 伴随着 9iR2 版本引入的主动间隔处理(proactive gap resolution) 技术的使用, 几乎物理或逻辑备库上任何类型的间隔请求都可以由主库上的 ping 进程来处理了.
在主库的正常工作过程中, 归档进程 (被指定为 ping 进程) 会轮流查询所有的备库来寻找 redo 间隔, 与此同时处理任何应用进程发来的未解决的间隔请求. 当物理备库需要从主库之外的数据库中获得间隔文件时就可以使用 FAL 技术. 举个例子, 比如物理备库现在需要进行间隔处理, 但是主库无法访问, 那么它需要去请求其他的备库来完成间隔处理, 为此, 你要将 FAL_SERVER 参数定义为指向主库或者任意备库的 TNS 标识符列表. 如在 Matrix_DR0 库中加入主库 (Matrix) 和其他备库(Matrix_DR1):
代码如下:
fal_server='Matrix, Matrix_DR1'
FAL_CLIENT FAL 客户端就是发起间隔请求的数据库的 TNS 名称, 间隔请求的接收方 (FAL_SERVER) 需要这个 TNS 名称以使得 FAL 服务器上的数据库可以反向连接至请求方. 在备库 Matrix_DR0 上, 我们发送 Matrix_DR0 作为客户端名称以便 Matrix 和 Matrix_DR1 库可以连接回 Matrix_DR0 库发送缺失的归档日志文件.
代码如下:
fal_client='Matrix_DR0'
'Matrix_DR0必须要在 FAL 服务器的 TNS 文件中定义以使得 DG 能够成功连接备库; 因为我们将会在所有这些数据库中设置 redo 传输参数, 所以我们也要为它们配置 TNS 名称. 如果你在 FAL 参数中使用相同的 TNS 名称, 那么这些 TNS 名称就是定义好的了. 如果你选择了一个不同的名称, 你就需要在所有系统的 TNS 文件中添加这个名称. 和 FAL_SERVER 参数一样, FAL_CLIENT 参数只对物理备库有效.
STANDBY_FILE_MANAGEMENT 这是本章节讨论的最后一个参数了. 这个简单的参数只用于物理备库. 该参数设置成 AUTO 的时候, 主库中添加和删除数据文件的同时, 备库中也会自动的进行相应的更改. 只要备库中顶级目录存在或能够借助于 DB_
FILE_NAME_CONVERT 参数找到, 那么 DG 将会执行 DDL 语句在备库中创建数据文件. 它甚至会尽可能的创建缺失的子目录. 默认情况下, 这个参数的值为 MANUAL, 这意味着备库上的应用进程不会创建新的数据文件, 你需要手动创建它们.
代码如下:
standby_file_management='AUTO'
只有当需要对物理备库上的 ORL 文件执行定义操作的时候, 我们才可能会将该参数设置成 MANUAL.SRL 文件能够在不改这个参数的情况下添加. 如果你真要在物理备库上添加或删除在线日志文件(比如因为主库上发生了更改), 你也可以将这个参数动态的设置成 MANUAL, 执行 DDL 操作, 然后再还原成 AUTO 值, 无需重启备库.
参数与属性小结
在了解上面的所有参数和属性之后, 你应该对它们的功能和特性有了深刻的理解并且可以正确的配置使用了.
希望你不要对这些感到头疼, 因为有一点你或许会感到诧异: 如果你使用 Data Guard Broker(即使不用 Grid Control), 就没必要亲自配置这些参数了, DG Broker 会为你做好一切.
-- END --
来源: http://www.bubuko.com/infodetail-2723138.html