第四部分Standby之REDO传输服务 2007.12.18
很多人看电影或者电视剧时往往都以为，影响剧情发展的关键是主角的命运，那么，我不得不又说，你只看到了问题的表面，真正影响剧情发展的...............是导演。对于data guard 的数据应用而言，幕后的导演是LOG_ARCHIVE_DEST_n。本章节我们要学习的内容会很多，这一次，希望你能理清要学习的重点。
关于redo 传输服务(Redo Transport Services)，它不仅控制着传输redo 数据到其它数据库，同时还管理着解决由于网络中断造成的归档文件未接收的过程。
一、如何发送数据
在primary 数据库，DataGuard 可以使用归档进程(ARCn)或者日志写进程(LGWR)收集redo 数据并传输到standby，不过不管你选择归档进程也好，日志写进程也好，都由一个核心参数来控制，它就是：LOG_ARCHIVE_DEST_n，所以，我们先来：
1、认识LOG_ARCHIVE_DEST_n参数
LOG_ARCHIVE_DEST_n(n 从1 到10)定义redo 文件路径。该参数定义必须通过location 或service 指明归档文件路径。location 表示本地路径，service 通常是net service name，即接收redo 数据的standby 数据库。
提示：
对于每一个LOG_ARCHIVE_DEST_n 参数，还有一个对应的LOG_ARCHIVE_DEST_STATE_n 参数。LOG_ARCHIVE_DEST_STATE_n 参数用来指定对应的LOG_ARCHIVE_DEST_n 参数是否生效，拥有4 个属性值：
● ENABLE：默认值，表示允许传输服务。
● DEFER：该属性指定对应的log_archive_dest_n 参数有效，但暂不使用。
● ALTERNATE：禁止传输，但是如果其它相关的目的地的连接通通失败，则它将变成enable。
● RESET：功能与DEFER 属性类似，不过如果传输目的地之前有过错误，它会清除其所有错误信息。
例如：指定本地归档路径
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
又比如，指定redo 传输服务
LOG_ARCHIVE_DEST_2='SERVICE=jsspdg'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
当然，LOG_ARCHIVE_DEST_n 参数的属性远不止这些。
这些参数都可以通过alter system set 语句直接联机修改，修改会在primary 下次日志切换时生效，当然你直接shutdown 再重启数据库的话也会即时生效:)比如：
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=jsspdgVALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)';
除show parameter log_archive_dest 外，还可以通过查询V$ARCHIVE_DEST 视图的方式查看参数配置，并且V$ARCHIVE_DEST 视图还可以看到更详细的同步信息。
2、使用ARCARCn归档redo数据
默认情况下，redo 传输服务使用ARCn 进程归档redo 日志。不过ARCn 归档进程只支持最高性能的保护模式。如果standby 数据库处于其它类型的保护模式，那你必须使用LGWR 传输redo 数据(为什么会这样呢，三思再来白话几句，我们知道对于最大保护和最高可用性两种模式而言，其实强调的都是一点，redo数据必须实时应用于standby 数据库，我们再看来归档，归档是做什么呢？是备份已完成切换的redolog，完成切换的redolog 代表着什么呢？说明该redo 中所有数据均已提交至数据文件，那好我们再回过头来看，数据已完成提交的redo 并且完成了切换还被复制了一份做为归档，这个时候才准备开始传输到standby 数据库，这与最大保护和最高可用所要求的实时应用差的简直不是一点半点，现在，你是不是明白了为什么ARCn 归档进程只能支持最高性能的保护模式)。
1).初始化参数控制ARCn 归档行为
影响ARCn 进程的初始化参数有：
LOG_ARCHIVE_DEST_n 及LOG_ARCHIVE_MAX_PROCESSES。
关于LOG_ARCHIVE_DEST_n 参数的配置前面介绍了一些，我们知道该参数的部分属性与ARCn进程相关，而LOG_ARCHIVE_MAX_PROCESSES 初始化参数则可看做是专为ARCn 进程量身打造，该参数用来指定最大可被调用的ARCn 进程的数量，注意我们指定的是最大值，也就是说数据库在运行过程中是会根据归档的任务繁重程度自动调节归档进程数量的。当然如果说你觉着你的系统归档任务比较繁重，可以通过设置较多的归档进程数量提高归档并发度，但是这个数字也不是越高越好，过高的归档进程数量有可能反而影响系统性能(所谓物极必反就是这个意思，所以这中间是需要你来把握平衡的，当然这方面更多涉及到调优了，非本章所要讲解之重点，就不多说了)。调整该参数可以通过下列语句：
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES = n;
注：n>0 and n<=30
2).ARCn 的归档过程
primary 数据库日志发生切换时就会启动归档：
● 在primary 数据库(假设有2 个归档进程)，一旦ARC0 进程完成redolog 的归档，ARC1 进程即开始传输该归档到standby 数据库的指定路径。
● 在standby 数据库，RFS 进程轮流将redo 数据写入standby redo log，再由standby 数据库中的ARCn 进程将其写入归档，然后通过REDO 应用或SQL 应用将数据应用到standby 数据库。
如图：
另外，因为本地的归档进程与远程归档进程间并无联系，注意如果本地存在删除完成备份的归档的策略，需要在删除之前首先确认这些归档已经被传输到standby 数据库。
3、使用LGWR归档redo数据
使用LGWR 进程与使用ARCn 进程有明显不同，LGWR 无须等待日志切换及完成归档。
Standby 数据库的LGWR 进程会先选择一个standby redo log 文件映射primary 数据库当前redolog 的sequence(以及文件大小)，一旦primary 数据库有redo 数据产生，视LOG_ARCHIVE_DEST_n 初始化参数中sync 或async 属性设置，以同步或非同步方式传输到standby 数据库。
要继续下面的内容，我们必须先了解与LGWR 归档进程密切相关的几个LOG_ARCHIVE_DEST_n 参数的属性，如果选择LGWR 归档redo 数据，那么在LOG_ARCHIVE_DEST_n中必须指定SERVICE 和LGWR属性以允许日志传输服务使用LGWR 进程来传送redo 数据到远程归档目的地。我们还需要指定SYNC(同步)还是ASYNC(异步)的传输方式，如果指定SYNC 属性(如果不明确指定的话，默认是SYNC)，则primary数据库任何会产生redo 操作都会同步触发网络I/O，并且等到网络I/O 全部完成才会继续下面的提交，而如果指定了ASYNC 属性，则会primary 数据库的操作会先记录online redologs，然后再传输到standby。下面详细看看其流程：
1).LGWR 同步归档的流程
例如初始化参数中有如下设置：
LOG_ARCHIVE_DEST_1='LOCATION=E:\ora10g\oradata\jssweb\'
LOG_ARCHIVE_DEST_2='SERVICE=jsspdg LGWR SYNC NET_TIMEOUT=30'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
如果设置LOG_ARCHIVE_DEST_n 初始化参数SYNC 属性，建议同时设置NET_TIMEOUT 属性，该属性控制网络连接的超时时间，如果超时仍无响应，则会返回错误信息。
如图：
展示了primary 数据库LGWR 写online redologs 的同时，同步传输redo 数据到standby 数据库的过程。
我们仍然分两部分来解读：
● 在primary 数据库，LGWR 提交redo 数据到LNSn(LGWR Network Server process)进程(n>0)，LNSn 启动网络传输。
● standby 数据库的RFS(Remote File Server)将接收到的redo 数据写入standby redolog。特别注意， 在此期间， primary 数据库的事务会一直保持， 直到所有所有含LGWR SYNC 属性的LOG_ARCHIVE_DEST_n 指定路径均已完成接收。
一旦primary 数据库执行日志切换，就会级联触发standby 的ARCn 将standby redo 写入归档，然后通过redo 应用(MRP 进程)或sql 应用(LSP 进程)读取归档文件将数据应用至standby 数据库。(如果启用了实时应用的话，MRP/LSP 会直接读取standby redolog 并应用到standby 数据库，无须再等待归档)。
2).LGWR 不同步归档的流程
例如初始化参数中有如下设置：
LOG_ARCHIVE_DEST_1='LOCATION=E:\ora10g\oradata\jssweb\ '
LOG_ARCHIVE_DEST_2='SERVICE=jsspdg LGWR ASYNC'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
ASYNC 方式归档就不需要再指定NET_TIMEOUT 了，因为LGWR 与LNSn 之间已无关联，所以指定不指定NET_TIMEOUT 就都没任何影响了，因此对于异步传输而言，即使网络出现故障造成primary 与standby 之间通信中断，也并不会影响到primary 数据库的提交。
如图：
展示了LNSn 进程异步传输redo 数据到standby 数据库RFS 进程的过程。
大致步骤与同步传输相同，差别只在LNSn 进程这里，LGWR 写数据到online redolog，LNSn 进程访问online redolog 并传输数据到远程standby 的RFS 而不再与本地LGWR 之间有联系。standby 数据库方面的处理逻辑仍然不变。
二、什么时候发送
这小节包含两个内容，发送什么，以及发送给谁：
1、通过VALID_FOR 属性指定传输及接收对象
valid_for，字面理解就是基于xx 有效，再配合其redo_log_type,database_role 属性，我们基本上可以将其理解为：为指定角色设置日志文件的归档路径，主要目的是为了辅助一旦发生角色切换操作后数据库的正常运转。
redo_log_type 可设置为：ONLINE_LOGFILE，STANDBY_LOGFILE，ALL_LOGFILES
database_role 可设置为：PRIMARY_ROLE，STANDBY_ROLE，ALL_ROLES
注意valid_for 参数是有默认值的，如果不设置的话，其默认值等同于：valid_for=(ALL_LOGFILES,ALL_ROLES)
推荐主动设置该参数而不要使用默认值，某些情况下默认的参数值不一定合适，比如逻辑standby 就不像物理standby ，逻辑standby 处于open 模式， 不仅有redo 数据而且还包含多种日志文件(onlineredologs,archived redologs 以及standby redologs)。多数情况下，逻辑standby 生成的online redologs 与standbyredologs 生成在相同的目录内。因此，推荐你对每个*dest 设置合适的valid_for 属性。
2、通过DB_UNIQUE_NAME 属性指定数据库
DB_UNIQUE_NAME 属性主要是为某个数据库指定唯一的数据库名称，这就使得动态添加standby 到包含RAC 结构的primary 数据库的dg 配置成为可能，并且对于log_archive_dest_n 中的service 属性，其属
性值对应的也必然是db_unique_name，也正因有了db_unique_name，redo 数据在传输过程中才能确认传输到你希望被传输到的数据库上。当然要保障传输redo 数据到指定服务器， 除了db_unique_name,log_archive_dest_n 之外，还有一个初始化参数：log_archive_config。
关于log_archive_config 呢，我们前面有过一些接触，在第二部分第1 节中也有一些简单的介绍，log_archive_config 初始化参数还包括几个属性， 可以用过控制数据库的传输和接收，SEND,NOSEND,RECEIVE,NORECEIVE：
● SEND 允许数据库发送数据到远端
● RECEIVE 则允许standby 接收来自其它数据库的数据
● NOSEND,NORECEIVE 自然就是禁止喽。
例如，设置primary 数据库不接收任何归档数据，可以做如下的设置：
LOG_ARCHIVE_CONFIG='NORECEIVE,DG_CONFIG=(jssweb,jsspdg)'
当然，你同样也需要注意，一旦做了如上的设置，那么假设该服务器发生了角色切换，那它仍然也没有接收redo 数据的能力哟。
三、出错了咋整
对于归档失败的处理，LOG_ARCHIVE_DEST_n 参数有几个属性可以用来控制一旦向归档过程中出现故障时应该采取什么措施，它们是：
1、REOPEN 指定时间后再次尝试归档
使用REOPEN=seconds(默认=300)属性，在指定时间重复尝试向归档目的地进行归档操作，如果该参数值设置为0，则一旦失败就不会再尝试重新连接并发送，直到下次redo 数据再被归档时会重新尝试，不过并不会归档到已经失败的归档目的地，而是向替补的归档目的地发送。
2、ALTERNATE 指定替补的归档目的地
alternate 属性定义一个替补的归档目的地，所谓替补就是一旦主归档目的地因各种原因无法使用，则临时向alternate 属性中指定的路径写。
需要注意一点，reopen 的属性会比alternate属性优先级要高，如果你指定reopen 属性的值>0，则lgwr/arch会首先尝试向主归档目的地写入，直到达到最大重试次数，如果仍然写入失败，才会向alternate 属性指定的路径写。
3、MAX_FAILURE 控制失败尝试次数
max_failure 属性指定一个最大失败尝试次数，大家应该能够联想到reopen，没错两者通常是应该配合使用，reopen 指定失败后重新尝试的时间周期，max_failure 则控制失败尝试的次数，如例：
LOG_ARCHIVE_DEST_1='LOCATION=E:\ora10g\oradata\jsspdg\ REOPEN=60 MAX_FAILURE=3'
四、管理归档中断
如果primary 数据库中的归档日志没能成功发送至standby 数据库，就会出现归档中断。当然通常情况下你不需要担心这一点，因为dg 会自动检测并尝试复制丢失的归档以解决中断问题，通过什么解决呢？
FAL(FetchArchive Log)。
FAL 分server 和client，前面创建步骤中讲初始化参数时想必大家也注意到了。FAL client 自动主动要求传
输归档文件，FAL server 则响应FAL client 发送的请求。多好的两口子啊。
FAL 机制会自动处理下列类似的归档中断问题：
● 当创建物理或逻辑的standby 数据库，FAL 机制会自动获取primary 数据库热备时产生的归档文件。
● 当接收的归档文件出现下列的问题时，FAL 机会会自动获取归档文件解决：
※ 当接收到的归档在应用之后被删除时；
※ 当接收到的归档所在磁盘损坏时；
● 当存在多个物理standby 时，FAL 机制会自动尝试从其它standby 服务器获取丢失的归档文件。
让大家了解这个东西不是为了让你做什么，而是希望你放心，oracle 会管理好这些，如果它没有管理好，你明白这个原理，你也能分析一下它为什么没能管理好，通过什么方式能够促使它恢复有效管理的能力，当然你一定要自己动手，也可以，下面通过示例来说明手工处理归档中断（注意，俺只描述步骤，演示俺就不做了。因为三思现在用地最大保护模式，不会丢失归档地说，哇哈哈哈:)）
1、首先你要确认一下standby 是否存在归档中断
可以通过查询v$archive_gap 视图来确定，如果有记录就表示有中断。
SQL> select *from v$archive_gap;
这一步的目的是为了取出对应的LOW_SEQUENCE#和HIGH_SEQUENCE#，如果有RAC 的话，还需要注意一下THREAD#。
2、查找sequence 对应的归档文件
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 ANDSEQUENCE# BETWEEN 7 AND 10;
3、复制对应的归档文件到standby
注意，如果是RAC 的话，要找对机器哟:)
然后通过alter database register logfile 命令将这些文件重新注册一下，例如：
SQL> ALTER DATABASE REGISTER LOGFILE 'e:\ora10g\jsspdg\xxxx.arc';
然后重启redo 应用即可。
对于逻辑standby 的丢失归档处理稍微复杂一点点，因为逻辑standby 没有提供类型v$archive_gap;之类的视图，因此我们需要自己想办法来识别是否存在丢失的情况，具体可以通过下列的语句：
SQL> select thread#,sequence#,file_name from dba_logstdby_log l
2 where next_change# not in (
3 select first_change# from dba_logstdby_log where l.thread# = thread#)
4 order by thread#,sequence#;
找出丢失的归档文件后，接着的处理方式与物理standby 相同。