Data Guard学习物理standby REDO传输服务
二、什么时候发送
这小节包含两个内容，发送什么，以及发送给谁：
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：
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'
四、选择数据保护模式
关于有三模同学的光荣事迹大家都听说过了，有不认识的请自觉重温"名词先混个脸熟"篇，下面让三思就有三模同学的高超本领为大家做个展示。
为了便于大家更好的理解，我们先画一个表，表中描述了不同保护模式下LOG_ARCHIVE_DEST_n参数应该设置的属性：
|
|
最大保护
|
最高可能用
|
最高性能
|
|
REDO写进程
|
LGWR
|
LGWR
|
LGWR或ARCH
|
|
网络传输模式
|
SYNC
|
SYNC
|
LGWR进程时SYNC或ASYNC，ARCH进程时SYNC
|
|
磁盘写操作
|
AFFIRM
|
AFFIRM
|
AFFIRM或NOAFFIRM
|
|
是否需要standby redologs
|
YES
|
YES
|
可没有但推荐有
|
提示：
上面中的各项需求都是满足该保护模式的最低需求，这些需求都是据其特性而定的，同时你也一定要理解，这些需求仅只是保证你完成data guard保护模式的设置，如果你真正理解其特性的需求所希望满足的原因，你还需要做不少其它必要的工作。比如对于最高可用性而言，其根本目地是为了在某一台甚至多台主或备库瘫痪时，数据库仍能够在极短时间内恢复服务，这就不仅需要你将最高可用性保护模式的参数配置正确，还需要你拥有足够多的standby数据库。听明白了没？啥，木有？555555555，你在打击俺语言描述的能力~~~
另外再强调一遍：最大保护和最高可用性都要求standby数据库配置standby redo logs(当然如果考虑角色切换的话，主库肯定也是需要配置的)，关于standby redo logs的故事你可以参考第二部分的第一章1.3。
下面我们进入实践将一个data guard配置从最高性能模式改为最高可用性模式：
1、首先查看当前的保护模式 ---primary数据库操作
SQL> select protection_mode,protection_level from v$database;
PROTECTION_MODE PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE
2、修改初始化参数 --primary数据库操作
SQL> alter system set log_archive_dest_2='SERVICE=jsspdg
2 OPTIONAL LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
3 DB_UNIQUE_NAME=jsspdg';
系统已更改。
3、设置新的数据保护模式并重启数据库 --primary数据库操作
语句非常简单，如下：
SQL> alter database set standby database to maximize availability;
数据库已更改。
提示：maximize后可跟{PROTECTION | AVAILABILITY | PERFORMANCE}，分别对应最大保护，最高可用性及最高性能。
Down掉数据库，重新启动
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area 167772160 bytes
Fixed Size 1289484 bytes
Variable Size 121635572 bytes
Database Buffers 37748736 bytes
Redo Buffers 7098368 bytes
数据库装载完毕。
数据库已经打开。
4、看一下当前的保护模式 --primary数据库操作
SQL> select protection_mode,protection_level from v$database;
PROTECTION_MODE PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY
5、修改standby初始化参数设置(主要考虑角色切换，如果只测试的话本步可跳过) ---standby数据库操作
SQL> alter system set log_archive_dest_2='SERVICE=jssweb OPTIONAL LGWR SYNC AFFIRM
2 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=jssweb';
系统已更改。
查看当前的保护模式
SQL> select instance_name from v$instance;
INSTANCE_NAME
----------------
jsspdg
SQL> select protection_mode,protection_level from v$database;
PROTECTION_MODE PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY
配置成功，正面顺便再测试一下。
6、停掉standby数据库，再查看primary数据库状态
SQL> select protection_mode,protection_level from v$database;
PROTECTION_MODE PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM AVAILABILITY RESYNCHRONIZATION
Standby数据库shutdown后，primary数据库保护级别切换为待同步。
0
相关文章
关注我们
