Oracle DG 最大保护（Maximize Protection)和最高可用性（Maximize Availability）异同

Oracle DG 最大保护（Maximize Protection)和最高可用性（Maximize Availability）异同

系统环境：

操作系统：RedHat EL5

Oracle： Oracle 11gR2

如图所示：

主数据库（生产库）： BJDB

备        库 （容灾库）： SHDB

Oracle DG 数据保护模式：

       DataGuard允许定义3钟数据保护模式，分别是最大保护（Maximum Protection），最大可用（Maximum Availability）和最大性能（Maximum Performance）。

1.最大保护（Maximum Protection）

这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其REDO不仅被写入到本地的OnlineRedologs，还要同时写入到Standby数据库的StandbyRedologs，并确认REDO数据至少在一个Standby数据库中可用（如果有多个的话），然后才会在Primary数据库上提交。如果出现了什么故障导致Standby数据库不可用的话（比如网络中断），Primary数据库会被Shutdown，以防止数据丢失。

使用这种方式要求StandbyDatabase必须配置StandbyRedoLog，而PrimaryDatabase必须使用LGWR，SYNC，AFFIRM方式归档到StandbyDatabase.

2.最高可用性（Maximumavailability）

这种模式在不影响Primary数据库可用前提下，提供最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求本地事务在提交前必须至少写入一台Standby数据库的StandbyRedologs中，不过与最大保护模式不同的是，如果出现故障导致Standby数据库无法访问，Primary数据库并不会被Shutdown，而是自动转为最高性能模式，等Standby数据库恢复正常之后，Primary数据库又会自动转换成最高可用性模式。

这种方式虽然会尽量避免数据丢失，但不能绝对保证数据完全一致。这种方式要求StandbyDatabase必须配置StandbyRedoLog，而PrimaryDatabase必须使用LGWR，SYNC，AFFIRM方式归档到StandbyDatabase.

3.最高性能（Maximumperformance）

缺省模式。这种模式在不影响Primary数据库性能前提下，提供最高级别的数据保护策略。事务可以随时提交，当前Primary数据库的REDO数据至少需要写入一个Standby数据库，不过这种写入可以是不同步的。如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护，而仅对Primary数据库的性能有轻微影响。这也是创建Standby数据库时，系统的默认保护模式。

这种方式可以使用LGWRASYNC或者ARCH进程实现，StandbyDatabase也不要求使用StandbyRedoLog。

  默认Oracle DG 数据保护模式采用Maximum Performance，从Maximum Performance到 Maximum Protection，见以下blog：

http://tiany.blog.51cto.com/513694/1382731

Oracle DataGuard之---最大保护模式（Maximum Protection）

案例思路：

在主库完成transaction commit之前，断开主库和备库的网络；主库没有收到备库返回的接收日志的确认，转换最大性能模式。

1、从最大保护切换到最高可用性

主库：

22:36:04 SYS@ TestDB12>select name,database_role,protection_mode from v$database;

NAME      DATABASE_ROLE    PROTECTION_MODE

--------- ---------------- --------------------

TESTDB12  PRIMARY          MAXIMUM PROTECTION

Elapsed: 00:00:00.02

23:20:44 SYS@ TestDB12>startup mount;

ORACLE instance started.

Total System Global Area  643026944 bytes

Fixed Size                  2231112 bytes

Variable Size             419431608 bytes

Database Buffers          218103808 bytes

Redo Buffers                3260416 bytes

Database mounted.

23:23:35 SYS@ TestDB12>alter database set standby database to maximize availability;

Database altered.

Elapsed: 00:00:00.04

23:24:01 SYS@ TestDB12>alter database open;

Database altered.

Elapsed: 00:00:01.00

23:24:33 SYS@ TestDB12>select name,database_role,protection_mode from v$database;

NAME      DATABASE_ROLE    PROTECTION_MODE

--------- ---------------- --------------------

TESTDB12  PRIMARY          MAXIMUM AVAILABILITY

Elapsed: 00:00:00.00

23:24:59 SYS@ TestDB12>

备库：

23:18:44 SYS@ shdb>select name,database_role,protection_mode from v$database;

NAME      DATABASE_ROLE    PROTECTION_MODE

--------- ---------------- --------------------

TESTDB12  PHYSICAL STANDBY MAXIMUM AVAILABILITY

Elapsed: 00:00:00.02

23:25:59 SYS@ shdb>

2、验证最高可用性：

主库：

23:28:19 SYS@ TestDB12>insert into scott.emp1 select * from scott.emp where rownum <5;

4 rows created.

Elapsed: 00:00:00.00

23:28:43 SYS@ TestDB12>select count(*) from scott.emp1;

 COUNT(*)

----------

       32

Elapsed: 00:00:00.00

23:28:48 SYS@ TestDB12>commit;

Commit complete.

  在完成commit 之前，断开备库的网络，主库没有收到备库返回接收日志的确认，在最高可用性模式下，主库主动去切换日志（而不是关闭实例），将在线日志写入归档日志！

如下告警日志所示：

告警日志：

ORA-16198: LGWR received timedout error from KSR

LGWR: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (16198)

LGWR: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned

Error 16198 for archive log file 3 to 'shdb'

Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED

Thread 1 cannot allocate new log, sequence 62

Checkpoint not complete

 Current log# 3 seq# 61 mem# 0: /dsk1/oradata/bj/redo03a.log

 Current log# 3 seq# 61 mem# 1: /dsk2/oradata/bj/redo03b.log

LGWR: Failed to archive log 3 thread 1 sequence 61 (16198)

Thread 1 advanced to log sequence 62 (LGWR switch)

 Current log# 1 seq# 62 mem# 0: /dsk1/oradata/bj/redo01a.log

 Current log# 1 seq# 62 mem# 1: /dsk2/oradata/bj/redo01b.log

Thu Apr 24 23:29:42 2014

Archived Log entry 89 added for thread 1 sequence 61 ID 0xa91f3cda dest 1:

主库状态：

23:18:44 SYS@ shdb>select name,database_role,protection_mode from v$database;

NAME      DATABASE_ROLE    PROTECTION_MODE

--------- ---------------- --------------------

TESTDB12  PHYSICAL STANDBY MAXIMUM AVAILABILITY

23:34:03 SYS@ TestDB12>select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)

--------------

           61

备库状态：

23:36:24 SYS@ shdb>select name,database_role,protection_mode from v$database;

NAME      DATABASE_ROLE    PROTECTION_MODE

--------- ---------------- --------------------

TESTDB12  PHYSICAL STANDBY MAXIMUM AVAILABILITY

23:36:14 SYS@ shdb>select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)

--------------

           60

Elapsed: 00:00:00.01

注：主库和备库产生日志差异

备库在网络恢复正常后，主动的去检查日志gap，然后向主库索取归档日志，做recover，如下告警日志所示

RFS[9]: Assigned to RFS process 4153

RFS[9]: Selected log 5 for thread 1 sequence 61 dbid -1483137996 branch 820054583

Thu Apr 24 23:36:38 2014

Media Recovery Waiting for thread 1 sequence 62

Thu Apr 24 23:36:38 2014

Archived Log entry 63 added for thread 1 sequence 61 ID 0xa91f3cda dest 1:

Thu Apr 24 23:36:42 2014

Primary database is in MAXIMUM AVAILABILITY mode

Changing standby controlfile to RESYNCHRONIZATION level

Standby controlfile consistent with primary

RFS[10]: Assigned to RFS process 4155

RFS[10]: Selected log 4 for thread 1 sequence 63 dbid -1483137996 branch 820054583

Thu Apr 24 23:36:43 2014

RFS[11]: Assigned to RFS process 4157

RFS[11]: Selected log 5 for thread 1 sequence 62 dbid -1483137996 branch 820054583

Archived Log entry 64 added for thread 1 sequence 62 ID 0xa91f3cda dest 1:

Media Recovery Log /dsk4/arch_sh/arch_1_62_820054583.log

Media Recovery Waiting for thread 1 sequence 63 (in transit)

Recovery of Online Redo Log: Thread 1 Group 4 Seq 63 Reading mem 0

 Mem# 0: /dsk1/oradata/sh/std_redo04a.log

Changing standby controlfile to MAXIMUM AVAILABILITY level

RFS[10]: Selected log 5 for thread 1 sequence 64 dbid -1483137996 branch 820054583

Media Recovery Waiting for thread 1 sequence 64 (in transit)

Recovery of Online Redo Log: Thread 1 Group 5 Seq 64 Reading mem 0

 Mem# 0: /dsk1/oradata/sh/std_redo05a.log

Archived Log entry 65 added for thread 1 sequence 63 ID 0xa91f3cda dest 1:

主库和备库同步：

主库：

23:35:07 SYS@ TestDB12>select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)

--------------

           63

备库：

23:36:32 SYS@ shdb>select max(sequence#) from v$archived_log;

MAX(SEQUENCE#)

--------------

           63

@至此，验证成功！