Oracle DataGuard之---最大保护模式（Maximum Protection）
系统环境：
操作系统：RH EL55
Oracle 软件：Oracle 11gR2
一、DataGuard 工作原理
Data Gurad 通过冗余数据来提供数据保护，Data Gurad 通过日志同步机制保证冗余数据和主数之前的同步，这种同步可以是实时，延时，同步，异步多种形式。Data Gurad 常用于异地容灾和小企业的高可用性方案，虽然可以在Standby 机器上执行只读查询，从而分散Primary 数据库的性能压力，但是Data Gurad 决不是性能解决方案。
Stream 是以Oracle Advanced Queue为基础实现的数据同步，提供了多种级别的灵活配置，并且Oracle 提供了丰富的API等开发支持，Stream 更适用在应用层面的数据共享。
在Data Gurad 环境中，至少有两个数据库，一个处于Open 状态对外提供服务，这个数据库叫作Primary Database。第二个处于恢复状态，叫作Standby Database。运行时primary Database 对外提供服务，用户在Primary Database 上进行操作，操作被记录在联机日志和归档日志中，这些日志通过网络传递给Standby Database。这个日志会在Standby Database 上重演，从而实现Primary Database 和Standby Database 的数据同步。
Oracle Data Gurad 对这一过程进一步的优化设计，使得日志的传递，恢复工作更加自动化，智能化，并且提供一系列参数和命令简化了DBA工作。
如果是可预见因素需要关闭Primary Database，比如软硬件升级，可以把Standby Database 切换为Primary Database 继续对外服务，这样即减少了服务停止时间，并且数据不会丢失。如果异常原因导致Primary Database 不可用，也可以把Standby Database 强制切换为Primary Database继续对外服务，这时数据损失成都和配置的数据保护级别有关系。因此Primary 和Standby 只是一个角色概念，并不固定在某个数据库中。
二、DataGuard 组织架构
DG架构可以按照功能分成3个部分：
1） 日志发送（Redo Send）
2） 日志接收（Redo Receive）
3） 日志应用（Redo Apply）
三、DataGuard 数据保护模式
Data Guard 允许定义3钟数据保护模式，分别是最大保护（Maximum Protection），最大可用（Maximum Availability）和最大性能（Maximum Performance）。
1. 最大保护（Maximum Protection）
这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其REDO不仅被写入到本地的Online Redologs，还要同时写入到Standby数据库的Standby Redologs，并确认REDO数据至少在一个Standby数据库中可用（如果有多个的话），然后才会在Primary数据库上提交。如果出现了什么故障导致Standby数据库不可用的话（比如网络中断），Primary数据库会被Shutdown，以防止数据丢失。
使用这种方式要求Standby Database 必须配置Standby Redo Log，而Primary Database必须使用LGWR，SYNC，AFFIRM 方式归档到Standby Database.
2. 最高可用性（Maximum availability）
这种模式在不影响Primary数据库可用前提下，提供最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求本地事务在提交前必须至少写入一台Standby数据库的Standby Redologs中，不过与最大保护模式不同的是，如果出现故障导致Standby数据库无法访问，Primary数据库并不会被Shutdown，而是自动转为最高性能模式，等Standby数据库恢复正常之后，Primary数据库又会自动转换成最高可用性模式。
这种方式虽然会尽量避免数据丢失，但不能绝对保证数据完全一致。这种方式要求Standby Database 必须配置Standby Redo Log，而Primary Database必须使用LGWR，SYNC，AFFIRM 方式归档到Standby Database.
3. 最高性能（Maximum performance）
缺省模式。这种模式在不影响Primary数据库性能前提下，提供最高级别的数据保护策略。事务可以随时提交，当前Primary数据库的REDO数据至少需要写入一个Standby数据库，不过这种写入可以是不同步的。如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护，而仅对Primary数据库的性能有轻微影响。这也是创建Standby数据库时，系统的默认保护模式。
这种方式可以使用LGWR ASYNC 或者 ARCH 进程实现，Standby Database也不要求使用Standby Redo Log。
四、最大性能升级到最大保护
1、查看DG的数据保护模式
---主库
SYS@bj>
select name,PROTECTION_MODE,database_role,SWITCHOVER_STATUSfrom v$database;
NAME PROTECTION_MODE DATABASE_ROLE SWITCHOVER_STATUS
--------- -------------------- ---------------- --------------------
PROD MAXIMUM PERFORMANCE PRIMARY SESSIONS ACTIVE
Elapsed: 00:00:00.07
---备库
06:21:02 SYS@ sh >select name,PROTECTION_MODE ,database_role,SWITCHOVER_STATUSfrom v$database
06:25:002;
NAME PROTECTION_MODE DATABASE_ROLE SWITCHOVER_STATUS
--------- -------------------- ---------------- --------------------
PROD MAXIMUM PERFORMANCE PHYSICAL STANDBY SESSIONS ACTIVE
2、查看和配置 standby redo log
--- 主库
06:26:21 SYS@ bj>select GROUP#,THREAD# ,SEQUENCE# ,BYTES,STATUSfrom v$standby_log;
GROUP #THREAD #SEQUENCE #BYTES STATUS
---------- ---------- ---------- ---------- ----------
4 1 0 52428800 UNASSIGNED
5 1 0 52428800 UNASSIGNED
6 0 0 52428800 UNASSIGNED
7 0 0 52428800 UNASSIGNED
Elapsed: 00:00:00.01
---备库
06:25:02 SYS@ sh >select GROUP#,THREAD# ,SEQUENCE# ,BYTES,STATUSfrom v$standby_log;
no rows selected
Elapsed: 00:00:00.00
06:27:38 SYS@ sh >
----在备库上添加standby log
06:31:27 SYS@ sh >alter database add standby logfile group 4
06:32:492'/disk1/oradata/sh/std_redo04a.log' size 50m;
Database altered.
Elapsed: 00:00:00.25
06:33:17 SYS@ sh >alter database add standby logfile group 5
06:33:232'/disk1/oradata/sh/std_redo05a.log' size 50m;
Database altered.
Elapsed: 00:00:00.24
06:33:34 SYS@ sh >alter database add standby logfile group 6
06:33:402'/disk1/oradata/sh/std_redo06a.log' size 50m;
Database altered.
Elapsed: 00:00:00.33
06:33:51 SYS@ sh >alter database add standby logfile group 7
06:33:592'/disk1/oradata/sh/std_redo07a.log' size 50m;
Database altered.
Elapsed: 00:00:00.25
06:34:09 SYS@ sh >
06:34:09 SYS@ sh >select GROUP#,THREAD# ,SEQUENCE# ,BYTES,STATUSfrom v$standby_log;
GROUP #THREAD #SEQUENCE #BYTES STATUS
---------- ---------- ---------- ---------- ----------
4 0 0 52428800 UNASSIGNED
5 0 0 52428800 UNASSIGNED
6 0 0 52428800 UNASSIGNED
7 0 0 52428800 UNASSIGNED
Elapsed: 00:00:00.00
3、修改主库和备库远程日志传送的模式
在最大保护模式下：lgwr 必须用sync 的方式传送redolog
---主库修改
06:43:22 SYS@ bj >alter system set log_archive_dest_2='service=sh lgwr sync affirm VALID_FOR=(all_LOGFILES,all_ROLES) DB_UNIQUE_NAME=sh' scope=spfile;
---备库修改
06:43:22 SYS@ sh >alter system set log_archive_dest_2='service=bj lgwr sync affirm VALID_FOR=(all_LOGFILES,all_ROLES) DB_UNIQUE_NAME=bj' scope=spfile;
4、关闭主库，启动到mount下修改保护模式：（在主库上修改保护模式）
SQL> startup mount;
ORACLE instance started.
Total System Global Area 134814580 bytes
Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 143360 bytes
Database mounted.
SQL> alter database set standby database to maximize protection;
Database altered.
------查看模式
08:17:36 SYS@ bj>select name,PROTECTION_MODE ,database_role,SWITCHOVER_STATUSfrom v$database;
NAME PROTECTION_MODE DATABASE_ROLE SWITCHOVER_STATUS
--------- -------------------- ---------------- --------------------
PROD MAXIMUM PROTECTION PRIMARY SESSIONS ACTIVE
Elapsed: 00:00:00.01
-----打开主库
07:14:38 SYS@ bj>alter database open;
----备库做recover
07:40:32 SYS@ sh >alter database recover managed standby database disconnect from session;
Database altered.
----查看备库模式
07:51:48 SYS@ sh >select name,PROTECTION_MODE ,database_role,SWITCHOVER_STATUSfrom v$database;
NAME PROTECTION_MODE DATABASE_ROLE SWITCHOVER_STATUS
--------- -------------------- ---------------- --------------------
PROD MAXIMUM PROTECTION PHYSICAL STANDBY TO PRIMARY
Elapsed: 00:00:00.02
五、故障分析
------如果主库open时遇到以下错误：
注：
在10gR2的data guard中，按照上述步骤切换保护模式的时候却不成功。主库完成切换语句后再open就报错：ORA-03113: end-of-file on communication channel。看alert文件，报错ORA-16072: a minimum of one standby database destination is required。但实际上备库的standby logfile都已经建好了，解决方法如下：
解决方法：
将主备库的flashback打开：
启动到mount
SQL> select FLASHBACK_ON from v$database;
FLASHBACK_ON
------------------------------------
NO
SQL> alter database flashback on;
数据库已更改。
然后再切换到最大可用或者最大保护模式就ok了,切换前注意备库已经处于mount状态，并且主库原有的归档日志都已经全部复制到备库对应的归档目录下了，否则传送方式由arch改成lgwr后这些差异日志就无法自动传过去了。
如果在备库做过：alter database recover managed standby database finish ；
----主库open 错误
LGWR: Primary database is in MAXIMUM PROTECTION mode
Thu Dec 13 07:41:04 2012
Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED
LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR
ARC0 started with pid=17, OS id=7020
LNSb started with pid=20, OS id=7026
Thu Dec 13 07:41:07 2012
Errors in file /u01/app/oracle/admin/prod/bdump/bj_lgwr_6998.trc:
ORA-16143: RFS connections not allowed during or after terminal recovery
Thu Dec 13 07:41:07 2012
LGWR: Error 16143 verifying archivelog destination LOG_ARCHIVE_DEST_2
Thu Dec 13 07:41:07 2012
Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
LGWR: Error 16143 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'sh'
LGWR: Continuing...
LGWR: Minimum of 1 applicable standby database required
------备库错误
Physical Standby Database mounted.
Completed: ALTER DATABASEMOUNT
ARC2 started with pid=18, OS id=6821
ARC2: Becoming the 'no FAL' ARCH
Thu Dec 13 07:37:49 2012
ARC0: Becoming the heartbeat ARCH
Thu Dec 13 07:38:31 2012
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 6824
RFS[1]: Identified database type as 'physical standby'
RFS[1]: No connections allowed during/after terminal recovery.
Thu Dec 13 07:38:31 2012
Errors in file /u01/app/oracle/admin/sh/udump/sh_rfs_6824.trc:
ORA-16143: RFS connections not allowed during or after terminal recovery
Thu Dec 13 07:40:47 2012
原因：在备库上曾经执行了：
alter database recover managed standby database finish ；
-------导致RFS不能再被启动
六、验证最大保护模式的安全性：
----在备库将网络中断，主库告警日志出现以下错误提示：
Thu Dec 13 08:02:10 2012
ORA-16198: LGWR received timedout error from KSR
LGWR: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (16198)
ORA-16198: LGWR received timedout error from KSR
LGWR: Error 16198 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'sh'
LNSb started with pid=20, OS id=7153
Error 12560 received logging on to the standby
Thu Dec 13 08:02:40 2012
LGWR: Error 12560 attaching to RFS for reconnect
LNSb started with pid=20, OS id=7155
Error 12560 received logging on to the standby
Thu Dec 13 08:03:05 2012
------LNS服务，尝试多次连接后，然后会关闭主库数据库
