2013年（350）
分类： Oracle
2013-04-25 10:27:46
什么时候发送
这小节包含两个内容，发送什么，以及发送给谁：
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数据而且还包含多种日志文件(online redologs,archived redologs以及standby redologs)。多数情况下，逻辑standby生成的online redologs与standby redologs生成在相同的目录内。因此，推荐你对每个*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：
l SEND允许数据库发送数据到远端
l RECEIVE则允许standby接收来自其它数据库的数据
l 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(Fetch Archive Log)。
FAL分和client，前面创建步骤中讲初始化参数时想必大家也注意到了。FAL client自动主动要求传输归档文件，FAL server则响应FAL client发送的请求。多好的两口子啊。
FAL机制会自动处理下列类似的归档中断问题：
l 当创建物理或逻辑的standby数据库，FAL机制会自动获取primary数据库热备时产生的归档文件。
l 当接收的归档文件出现下列的问题时，FAL机会会自动获取归档文件解决：
? 当接收到的归档在应用之后被删除时；
? 当接收到的归档所在磁盘损坏时；
l 当存在多个物理standby时，FAL机制会自动尝试从其它standby服务器获取丢失的归档文件。
让大家了解这个东西不是为了让你做什么，而是希望你放心，会管理好这些，如果它没有管理好，你明白这个原理，你也能分析一下它为什么没能管理好，通过什么方式能够促使它恢复有效管理的能力，当然你一定要自己动手，也可以，下面通过示例来说明手工处理归档中断（注意，俺只描述步骤，演示俺就不做了。因为三思现在用地最大保护模式，不会丢失归档地说，哇哈哈哈:)）
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 AND SEQUENCE# 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相同。
