【DG】DG的3种保护模式

【DG】DG的3种保护模式

---

---

DG提供了3种数据保护模式：最大保护（Maximum Protection）、最高性能（Maximum Performance）和最高可用（Maximum Availability），如下表所示：

表 3-32 DG三种模式的区别

数据库异地备份方案

在对数据库计划实施异地备份时，需要理解异地备份的目的。一般情况下有两种异地备份的需求：一是确保业务的实时以及最大程度减少由于单点故障导致业务中断；二是确保数据的安全，当生产节点出现物理故障时能通过异地备份及时的恢复数据。

 非实时异地备份

     如果只需实现数据的安全，而毋须关注业务的恢复时间以及数据的丢失情况。 那么可以通过非实时的异地备份而简易实现。

    非实时的异地备份可以通过磁盘或者磁带介质来实现。

    采用磁带来实现数据的安全性是传统的异地备份方式，采用此种方式，主要受限于磁带的读写速度偏慢，当需要执行恢复时，如果数据量很大，恢复的时间那是相当漫长。另外，需要使用第三方备份软件实现数据与磁带之间的交互；

   采用磁盘来实现数据库的安全性备份是近年来相对流行的异地备份方式，主要由于目前磁盘价格便宜，并且读写速度相对较高，因而比较受用户的青睐。经常的做法是通过异地的存储或者主机做为备份节点，当生产节点的数据备份出来之后，通过网络传输至备份节点，确保备份的安全；采用此种方式备份，对网络稳定要求较高。如果在执行数据传输出现网络故障，那么传输将会中断。另外，如果采用异地主机作为备份节点，建议备份节点的操作系统类型、芯片架构与生产节点的一致。

 实时异地备份

近年来，由于业务的发展以及技术的飞越。很多实时的异地备份方案出现，极大程度确保了数据的安全以及业务的稳定性。针对 Oracle 数据库，目前主流使用 Oracle DataGuard、Oracle Goldengate 作为灾备技术实现数据库的实时异地备份。当然还有 Vertias 的相关存储镜像管理软件来实现。

    以下着重了解 Oracle DataGuard 的实现方式。

Oracle DataGuard 结构

 如上图所述，结构中的备用数据库分成物理备用数据库和逻辑备用数据库。

在物理备用数据库中，将重做日志使用数据库恢复功能来应用。

   在逻辑备用数据库中，将重做日志转换成 SQL，使用这些 SQL 在逻辑备用数据库上 自动操作。

DataGuard 的保护模式

   在 Data Guard 模式下，数据库的保护模式分成下列三种：

最大保护模式

1）这种模式提供了最高级别的数据保护能力；

2）要求至少一个物理备库收到重做日志后，主库的事务才能够提交；

3）主库找不到合适的备库写入时，主库会自动关闭，防止未受保护的数据出现；

 4）优点：该模式可以保证备库没有数据丢失；

5）缺点：备库的自动关闭会影响到主库的可用性，同时需要备库恢复后才能提交，对网络等客观条件要求非常的高，主库的性能会因此受到非常大的冲击。

最大可用性模式

1）该模式提供了仅次于“最大保护模式”的数据保护能力；

2）要求至少一个物理备库收到重做日志后，主库的事务才能够提交；

3）主库找不到合适的备库写入时，主库不会关闭，而是临时降低到“最大性能模式”模式，直到问题得到处理；

4）优点：该模式可以在没有问题出现的情况下，保证备库没有数据丢失，是一种折中的方法；

5）缺点：在正常运行的过程中缺点是主库的性能受到诸多因素的影响。

最大性能模式

1）该模式是默认模式，可以保证主数据库的最高可用性；

2）保证主库运行过程中不受备库的影响，主库事务正常提交，不因备库的任何问题影响到主库的运行；

4）优点：避免了备库对主数据库的性能和可用性影响；

5）缺点：如果与主库提交的事务相关的恢复数据没有发送到备库，这些事务数据将被丢失，不能保证数据无损失；

   采用 Oracle DataGuard，最大的受限在于主备数据库主机需要采用同芯片架构的主机。鉴于此，不能跨操作系统平台实现 Oracle DataGuard 的应用。另外，Oracle DataGuard 是 Oracle 企业版数据库的一种特性，毋须其它 license。

---

---

Data Guard是Oracle高可用性HA的重要解决方案。针对不同的系统保护需求，DG提供了三种不同类型的保护模式（Protection Mode），分别为：最大保护（Maximum Protection）、最大可用（Maximum Availability）和最大性能（Maximum performance）。在实际应用场景下，我们需要根据不同的业务场景和数据可用性需求，来设置DG环境的保护类型。

1、三种保护模式Protection Mode

三种保护模式是DG的核心概念。DG本质上是一种基于Redo Log的数据同步机制。Undo和Redo是Oracle早期奠定行业地位的核心技术。Undo负责记录事务操作的前镜像，而Redo负责记录事务操作的后镜像。在Oracle事务commit的动作中，写入日志文件是一个一定需要完成的动作。写入日志文件之后，即使立刻出现严重的实例终止事件，在重新启动实例的时候也会进行实例恢复动作，将事务落实。

在DG环境中，无论采用何种初始化方法，都是确保一个Primary和Standby的初始化数据一致，之后Primary一端接收的事务类型操作，均会以归档日志串列的方式传递到Standby端的standby redo log和归档日志列表中，最后重复应用这些日志，实现Primary和Standby端一致。

Primary和Standby是相互为备份的冗余结构，Standby跟随Primary的情况，反映了HA结构的可用性级别。理论上，最保险的策略是一个事务要保证在Primary和Standby上都提交了，才返回给用户说已经完成。这样是可以保证主备库完全一致的最保险做法。另一个极端情况，就是主库“自顾自”进行事务处理，独立将日志进行传输，也不用管日志是否传输到或者应用到。

针对不同的传输情况，DG区分为三种保护类型：

ü  最大可用模式Maximum Availability

在官方文档中，对这种模式的描述如下：

“This protection mode provides the highest level of data protection that is possible without compromising the availability of a primary database. Transactions do not commit until all redo data needed to recover those transactions has been written to the online redo log and to the standby redo log on at least one synchronized standby database. If the primary database cannot write its redo stream to at least one synchronized standby database, it operates as if it were in maximum performance mode to preserve primary database availability until it is again able to write its redo stream to a synchronized standby database.”

Maximum Availability模式下，事务只有在所有相关日志都被传输到至少一个Standby端日志的时候，才可以正式提交。但是，如果Primary在传输日志的过程中，发现所有standby端都不能进行传输，模式会退化到最大性能模式（Maximum Performance）工作方式。应该说，Maximum Availability是一种自适应的保护模式，当出现问题的时候，DG会退而求其次，确保Primary主库事务进行。

ü  最大性能模式（Maximum Performance）

官方文档中介绍如下：“This protection mode provides the highest level of data protection that is possible without affecting the performance of a primary database. This is accomplished by allowing transactions to commit as soon as all redo data generated by those transactions has been written to the online log. Redo data is also written to one or more standby databases, but this is done asynchronously with respect to transaction commitment, so primary database performance is unaffected by delays in writing redo data to the standby database(s).

This protection mode offers slightly less data protection than maximum availability mode and has minimal impact on primary database performance.

This is the default protection mode.”

最大性能模式是在不影响主库工作情况下，可以提供的最高数据保护级别。当事务进行提交的时候，主库不会去确认日志是否写入到备库中，更不会确认是否被apply。这种方式下，主库的工作性能是不会收到备库提交应用的影响的。当然，这种保护模式会有一定的事务数据丢失，但是绝对不会出现数据误提交的情况。

对DG而言，最大性能模式是默认的保护模式。当我们完成了DG安装之后，就自动进入了Maximum Performance模式。

ü  最大保护模式（Maximum Protection）

最大保护模式在官方中的描述为：

“This protection mode ensures that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover a transaction must be written to both the online redo log and to the standby redo log on at least one synchronized standby database before the transaction commits. To ensure that data loss cannot occur, the primary database will shut down, rather than continue processing transactions, if it cannot write its redo stream to at least one synchronized standby database.

Transactions on the primary are considered protected as soon as Data Guard has written the redo data to persistent storage in a standby redo log file. Once that is done, acknowledgment is quickly made back to the primary database so that it can proceed to the next transaction. This minimizes the impact of synchronous transport on primary database throughput and response time. To fully benefit from complete Data Guard validation at the standby database, be sure to operate in real-time apply mode so that redo changes are applied to the standby database as fast as they are received. Data Guard signals any corruptions that are detected so that immediate corrective action can be taken.”

最大保护模式是完全HA架构理想中的事务模式。如果Primary数据库进行一个事务，连带Standby数据库也要同步进行操作。如果由于网络、执行模式等原因，Standby不能够跟上主库的操作，那么主库会放弃事务，并且强制停库。

保护模式的三种和数据库之间传输日志的机制是密切相关的。主要体现是否同步传输Redo日志和对日志进行确认两个方面。我们配置三种日志模式，一定要以Log_Archive_Config参数配置为基础。

Maximum Availability	Maximum Performance	Maximum Protection
AFFIRM	NOAFFIRM	AFFIRM
SYNC	ASYNC	SYNC
DB_UNIQUE_NAME	DB_UNIQUE_NAME	DB_UNIQUE_NAME

下面通过一系列的测试，来分析三种保护模式的工作行为方式。

2、环境介绍

笔者使用环境为Oracle 11gR2，具体版本为11.2.0.4。主备库环境已经搭建完成，同步保护模式是采用默认方式。

主库信息：

SQL> select name, open_mode, database_role, protection_mode from v$database;

NAME      OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE

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

VLIFE     READ WRITE           PRIMARY          MAXIMUM PERFORMANCE

SQL> select instance_name from v$instance;

INSTANCE_NAME

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

vlife

主库与备库连接方式，采用默认的异步非确认方式。

SQL> select dest_id, dest_name, TRANSMIT_MODE, ASYNC_BLOCKS, AFFIRM TYPE, VALID_NOW, VALID_TYPE, VALID_ROLE, DB_UNIQUE_NAME from v$archive_dest where status<>'INACTIVE';

   DEST_ID DEST_NAME            TRANSMIT_MODE ASYNC_BLOCKS TYPE VALID_NOW        VALID_TYPE      VALID_ROLE   DB_UNIQUE_NAME

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

         1 LOG_ARCHIVE_DEST_1   SYNCHRONOUS              0 NO   YES              ALL_LOGFILES    ALL_ROLES    NONE

         2 LOG_ARCHIVE_DEST_2   ASYNCHRONOUS         61440 NO   YES              ONLINE_LOGFILE  PRIMARY_ROLE vlifesb

此时，传输通道配置。

SQL> show parameter LOG_ARCHIVE_DEST_2;

NAME                                 TYPE        VALUE

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

log_archive_dest_2                   string      SERVICE=vlifesb valid_for=(online_logfiles,primary_role) db_unique_name=vlifesb

log_archive_dest_20                  string     

log_archive_dest_21                  string     

备库信息如下：

SQL> select name, open_mode, database_role, protection_mode from v$database;

NAME      OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE

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

VLIFE     READ ONLY WITH APPLY PHYSICAL STANDBY MAXIMUM PERFORMANCE

SQL> select instance_name from v$instance;

INSTANCE_NAME

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

vlifesb

SQL> col dest_name for a20;

SQL> select dest_id, dest_name, TRANSMIT_MODE, ASYNC_BLOCKS, AFFIRM TYPE, VALID_NOW, VALID_TYPE, VALID_ROLE, DB_UNIQUE_NAME from v$archive_dest where status<>'INACTIVE';

   DEST_ID DEST_NAME            TRANSMIT_MODE ASYNC_BLOCKS TYPE VALID_NOW        VALID_TYPE      VALID_ROLE   DB_UNIQUE_NAME

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

         1 LOG_ARCHIVE_DEST_1   SYNCHRONOUS              0 NO   YES              ALL_LOGFILES    ALL_ROLES    NONE

         2 LOG_ARCHIVE_DEST_2   ASYNCHRONOUS         61440 NO   WRONG VALID_TYPE ONLINE_LOGFILE  PRIMARY_ROLE vlife

        32 STANDBY_ARCHIVE_DEST SYNCHRONOUS              0 NO   YES              ALL_LOGFILES    ALL_ROLES    NONE

SQL> show parameter LOG_ARCHIVE_DEST_2;

NAME                                 TYPE        VALUE

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

log_archive_dest_2                   string      SERVICE=vlife valid_for=(online_logfiles,primary_role) db_unique_name=vlife

log_archive_dest_20                  string     

log_archive_dest_21                  string     

3、最大可用模式Maximum Availability Mode测试

当前从默认的最大性能切换到最大可用模式，首先需要满足将日志传输模式进行修改。

SQL> alter system set log_archive_dest_2='SERVICE=vlifesb sync affirm net_timeout=30 valid_for=(online_logfiles,primary_role) db_unique_name=vlifesb';

System altered

SQL> select dest_id, dest_name, TRANSMIT_MODE, ASYNC_BLOCKS, AFFIRM TYPE, VALID_NOW, VALID_TYPE, VALID_ROLE, DB_UNIQUE_NAME, NET_TIMEOUT from v$archive_dest where status<>'INACTIVE';

   DEST_ID DEST_NAME            TRANSMIT_MODE ASYNC_BLOCKS TYPE VALID_NOW        VALID_TYPE      VALID_ROLE   DB_UNIQUE_NAME                 NET_TIMEOUT

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

         1 LOG_ARCHIVE_DEST_1   SYNCHRONOUS              0 NO   YES              ALL_LOGFILES    ALL_ROLES   NONE                                     0

         2 LOG_ARCHIVE_DEST_2   PARALLELSYNC             0 YES  YES              ONLINE_LOGFILE  PRIMARY_ROLE vlifesb                                 30

此时，将保护模式使用alter database进行设置。

SQL> alter database set standby database to maximize availability;

Database altered

SQL> select name, open_mode, database_role, protection_mode from v$database;

NAME      OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE

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

VLIFE     READ WRITE           PRIMARY          MAXIMUM AVAILABILITY

在切换动作的时候，主库日志情况如下：

Wed Oct 21 15:13:48 2015

alter database set standby database to maximize availability

Completed: alter database set standby database to maximize availability

Wed Oct 21 15:13:49 2015

Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED –发现没有同步，需要补充。

******************************************************************

LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2

******************************************************************

Wed Oct 21 15:13:49 2015

NSS2 started with pid=34, OS id=9186

LGWR: Standby redo logfile selected to archive thread 1 sequence 82

LGWR: Standby redo logfile selected for thread 1 sequence 82 for destination LOG_ARCHIVE_DEST_2

Thread 1 advanced to log sequence 82 (LGWR switch)

  Current log# 3 seq# 82 mem# 0: /u01/app/oracle/oradata/VLIFE/onlinelog/o1_mf_3_c1kb1c24_.log

  Current log# 3 seq# 82 mem# 1: /u01/app/oracle/fast_recovery_area/VLIFE/onlinelog/o1_mf_3_c1kb1c43_.log

Wed Oct 21 15:13:53 2015

Archived Log entry 104 added for thread 1 sequence 81 ID 0xfad4f44b dest 1:

Wed Oct 21 15:13:54 2015

ARC3: Archive log rejected (thread 1 sequence 81) at host 'vlifesb'

FAL[server, ARC3]: FAL archive failed, see trace file.

ARCH: FAL archive failed. Archiver continuing

ORACLE Instance vlife - Archival Error. Archiver continuing.

Wed Oct 21 15:14:42 2015

Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED

LGWR: Standby redo logfile selected to archive thread 1 sequence 83

LGWR: Standby redo logfile selected for thread 1 sequence 83 for destination LOG_ARCHIVE_DEST_2

Thread 1 advanced to log sequence 83 (LGWR switch)

  Current log# 1 seq# 83 mem# 0: /u01/app/oracle/oradata/VLIFE/onlinelog/o1_mf_1_c1kb19q4_.log

  Current log# 1 seq# 83 mem# 1: /u01/app/oracle/fast_recovery_area/VLIFE/onlinelog/o1_mf_1_c1kb19sb_.log

Wed Oct 21 15:14:42 2015

Archived Log entry 107 added for thread 1 sequence 82 ID 0xfad4f44b dest 1:

在Primary端，在进行切换之后，Oracle发现传输状态不是同步情况。于是自动加快进行日志传输和同步动作。在Standby端，也可以看到后续追赶动作。

SQL> select name, open_mode, database_role, protection_mode from v$database;

NAME      OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE

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

VLIFE     READ ONLY WITH APPLY PHYSICAL STANDBY MAXIMUM AVAILABILITY

Standby端上的日志追赶动作。

Wed Oct 21 08:27:05 2015

Primary database is in MAXIMUM PERFORMANCE mode

Re-archiving standby log 4 thread 1 sequence 80

Wed Oct 21 08:27:05 2015

Media Recovery Waiting for thread 1 sequence 81

RFS[14]: Assigned to RFS process 31500

RFS[14]: Selected log 5 for thread 1 sequence 81 dbid -87496857 branch 892734889

Wed Oct 21 08:27:05 2015

Archived Log entry 76 added for thread 1 sequence 80 ID 0xfad4f44b dest 1:

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

  Mem# 0: /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_5_c265gqd8_.log

  Mem# 1: /u01/app/oracle/fast_recovery_area/VLIFESB/onlinelog/o1_mf_5_c265gqj0_.log

Wed Oct 21 15:13:52 2015

Primary database is in MAXIMUM AVAILABILITY mode

Changing standby controlfile to MAXIMUM AVAILABILITY mode

Changing standby controlfile to RESYNCHRONIZATION level

Standby controlfile consistent with primary

RFS[15]: Assigned to RFS process 969

RFS[15]: Selected log 4 for thread 1 sequence 82 dbid -87496857 branch 892734889

Wed Oct 21 15:13:53 2015

Archived Log entry 77 added for thread 1 sequence 81 ID 0xfad4f44b dest 1:

Wed Oct 21 15:13:53 2015

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

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

  Mem# 0: /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_4_c265gc9q_.log

  Mem# 1: /u01/app/oracle/fast_recovery_area/VLIFESB/onlinelog/o1_mf_4_c265gcfk_.log

Wed Oct 21 15:14:41 2015

Archived Log entry 78 added for thread 1 sequence 82 ID 0xfad4f44b dest 1:

Wed Oct 21 15:14:41 2015

Media Recovery Waiting for thread 1 sequence 83

Wed Oct 21 15:14:42 2015

Primary database is in MAXIMUM AVAILABILITY mode

Changing standby controlfile to MAXIMUM AVAILABILITY level

Standby controlfile consistent with primary

RFS[16]: Assigned to RFS process 976

RFS[16]: Selected log 4 for thread 1 sequence 83 dbid -87496857 branch 892734889

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

  Mem# 0: /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_4_c265gc9q_.log

  Mem# 1: /u01/app/oracle/fast_recovery_area/VLIFESB/onlinelog/o1_mf_4_c265gcfk_.log

此时，两个库由于网络通畅，同步状态正常，同步测试正常。

（Maximium Availiablity模式下使用）

--主库下

SQL> create table t_m as select * from dba_objects where rownum<10;

Table created

--Standby下

SQL> select count(*) from t_m;

  COUNT(*)

----------

         9

如果此时中断应用日志，Standby情况如下：

SQL> alter database recover managed standby database cancel;

Database altered

SQL> select name, open_mode, database_role, protection_mode from v$database;

NAME      OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE

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

VLIFE     READ ONLY            PHYSICAL STANDBY MAXIMUM AVAILABILITY

日志情况如下：

Wed Oct 21 15:20:49 2015

alter database recover managed standby database cancel

Wed Oct 21 15:20:49 2015

MRP0: Background Media Recovery cancelled with status 16037

Errors in file /u01/app/oracle/diag/rdbms/vlifesb/vlifesb/trace/vlifesb_pr00_17539.trc:

ORA-16037: user requested cancel of managed recovery operation

Managed Standby Recovery not using Real Time Apply

Recovery interrupted!

Recovered data files to a consistent state at change 1692263

Wed Oct 21 15:20:49 2015

MRP0: Background Media Recovery process shutdown (vlifesb)

Managed Standby Recovery Canceled (vlifesb)

Completed: alter database recover managed standby database cancel

如果此时再中断监听器，中断连接。此时数据库不能做到实时同步。

[oracle@vLIFE-URE-OT-DB-STANDBY ~]$ lsnrctl stop

LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 21-OCT-2015 15:24:17

Copyright (c) 1991, 2013, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))

The command completed successfully

--主库

***********************************************************************

Fatal NI connect error 12541, connecting to:

 (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=172.16.19.90)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=vlifesb)(CID=(PROGRAM=oracle)(HOST=vLIFE-URE-OT-DB-PRIMARY)(USER=oracle))))

  VERSION INFORMATION:

        TNS for Linux: Version 11.2.0.4.0 - Production

        TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production

  Time: 21-OCT-2015 15:24:38

  Tracing not turned on.

  Tns error struct:

    ns main err code: 12541

   

TNS-12541: TNS:no listener

    ns secondary err code: 12560

    nt main err code: 511

   

TNS-00511: No listener

    nt secondary err code: 111

    nt OS err code: 0

Error 12541 received logging on to the standby

Check whether the listener is up and running.

PING[ARC2]: Heartbeat failed to connect to standby 'vlifesb'. Error is 12541.

强制日志切换。

SQL> alter system switch logfile;

System altered

SQL> alter system switch logfile;

System altered

SQL> alter system switch logfile;

System altered

SQL> select * from v$archive_dest_status;

   DEST_ID DEST_NAME            STATUS    TYPE           DATABASE_MODE   RECOVERY_MODE           PROTECTION_MODE     DESTINATION                                                                      STANDBY_LOGFILE_COUNT STANDBY_LOGFILE_ACTIVE ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# ERROR                                                                            SRL DB_UNIQUE_NAME                 SYNCHRONIZATION_STATUS SYNCHRONIZED GAP_STATUS

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

         1 LOG_ARCHIVE_DEST_1   VALID     LOCAL          OPEN            IDLE                    MAXIMUM PERFORMANCE /u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch                                                     0                     0                1            85               0            0                                                                                 NO  NONE                           CHECK CONFIGURATION   NO          

         2 LOG_ARCHIVE_DEST_2   ERROR     PHYSICAL       OPEN_READ-ONLY  IDLE                    RESYNCHRONIZATION    vlifesb                                                                                             3                      0                1            82               1           82 ORA-12541: TNS: ???à?????ò                                                       YES vlifesb                        CHECK CONNECTIVITY    NO           RESOLVABLE GAP

SQL> select recid, name, sequence# from v$archived_log where sequence#>82;

     RECID NAME                                                                              SEQUENCE#

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

       108 vlifesb                                                                                  83

       109 /u01/app/oracle/fast_recovery_area/VLIFE/archivelog/2015_10_21/o1_mf_1_83_c2ghkz         83

       110 /u01/app/oracle/fast_recovery_area/VLIFE/archivelog/2015_10_21/o1_mf_1_84_c2ghl0         84

       111 /u01/app/oracle/fast_recovery_area/VLIFE/archivelog/2015_10_21/o1_mf_1_85_c2ghl4         85

而standby端，归档日志就没有传输到。

SQL> select recid, name, sequence# from v$archived_log where sequence#>82;

     RECID NAME                                                                              SEQUENCE#

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

        79 /u01/app/oracle/fast_recovery_area/VLIFESB/archivelog/2015_10_21/o1_mf_1_83_c2gh         83

SQL> select group#, dbid, archived from v$standby_log;

    GROUP# DBID                                     ARCHIVED

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

         4 UNASSIGNED                               NO

         5 UNASSIGNED                               NO

         6 UNASSIGNED                               YES

此时，Primary和Standby的连接明显被中断，日志不能传送，也就达不到同步确认的设置要求。但是此时，Primary还是可以进行事务操作。

（事务可以进行）

SQL> insert into t_m select * from dba_objects where rownum<10;

9 rows inserted

SQL> commit;

Commit complete

此时，如果恢复两者连接，启动监听器和日志应用。

[oracle@vLIFE-URE-OT-DB-STANDBY ~]$ lsnrctl start

LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 21-OCT-2015 15:51:46

Copyright (c) 1991, 2013, Oracle.  All rights reserved.

Starting /u01/app/oracle/product/11.2.0/dbhome_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 11.2.0.4.0 - Production

System parameter file is /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora

Log messages written to

（篇幅原因，有省略…….）

SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered

之后主库和从库日志上进行归档日志传输和后续同步动作，篇幅原因，日志信息省略。

从上面实验中，我们可以看到最大可用性模式的核心即使“可用”。所谓可用，即使保证Primary和Standby整体的可用。如果在日志传输通路顺畅，两者之间会维持严格的同步关系，行为类似于最大保护模式。但是，如果连接或者同步动作不能满足要求，DG是不会终止实例运行，而是退而求其次，进行一种类似最大性能模式的工作方式。

4、最大保护模式Maximum Protection

最大保护模式是DG可以提供的最高保护级别，建立在日志同步传输和确认的基础上。同样，可以使用alter database方法进行设置。

SQL> alter database set standby database to maximize protection;

Database altered

主库上，可以查看到状态变化和日志情况。

SQL> select name, open_mode, database_role, protection_mode from v$database;

NAME      OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE

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

VLIFE     READ WRITE           PRIMARY          MAXIMUM PROTECTION

Wed Oct 21 16:17:46 2015

alter database set standby database to maximize protection

Completed: alter database set standby database to maximize protection

Wed Oct 21 16:17:50 2015

Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED

******************************************************************

LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2

******************************************************************

LGWR: Standby redo logfile selected to archive thread 1 sequence 89

LGWR: Standby redo logfile selected for thread 1 sequence 89 for destination LOG_ARCHIVE_DEST_2

Thread 1 advanced to log sequence 89 (LGWR switch)

  Current log# 1 seq# 89 mem# 0: /u01/app/oracle/oradata/VLIFE/onlinelog/o1_mf_1_c1kb19q4_.log

  Current log# 1 seq# 89 mem# 1: /u01/app/oracle/fast_recovery_area/VLIFE/onlinelog/o1_mf_1_c1kb19sb_.log

Wed Oct 21 16:17:50 2015

Archived Log entry 119 added for thread 1 sequence 88 ID 0xfad4f44b dest 1:

备库上信息也是同样变化信息。

SQL>  select name, open_mode, database_role, protection_mode from v$database;

NAME      OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE

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

VLIFE     READ ONLY WITH APPLY PHYSICAL STANDBY MAXIMUM PROTECTION

Wed Oct 21 15:52:45 2015

Primary database is in MAXIMUM AVAILABILITY mode

Changing standby controlfile to MAXIMUM AVAILABILITY level

Standby controlfile consistent with primary

RFS[21]: Assigned to RFS process 1172

RFS[21]: Selected log 4 for thread 1 sequence 88 dbid -87496857 branch 892734889

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

  Mem# 0: /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_4_c265gc9q_.log

  Mem# 1: /u01/app/oracle/fast_recovery_area/VLIFESB/onlinelog/o1_mf_4_c265gcfk_.log

Wed Oct 21 16:17:49 2015

Archived Log entry 84 added for thread 1 sequence 88 ID 0xfad4f44b dest 1:

Wed Oct 21 16:17:49 2015

Media Recovery Waiting for thread 1 sequence 89

Wed Oct 21 16:17:50 2015

Primary database is in MAXIMUM PROTECTION mode

Changing standby controlfile to MAXIMUM PROTECTION mode

Standby controlfile consistent with primary

RFS[22]: Assigned to RFS process 1358

RFS[22]: Selected log 4 for thread 1 sequence 89 dbid -87496857 branch 892734889

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

  Mem# 0: /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_4_c265gc9q_.log

  Mem# 1: /u01/app/oracle/fast_recovery_area/VLIFESB/onlinelog/o1_mf_4_c265gcfk_.log

如果此时，我们终止Standby端的同步动作。

SQL> alter database recover managed standby database cancel;

Database altered

SQL>  select name, open_mode, database_role, protection_mode from v$database;

NAME      OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE

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

VLIFE     READ ONLY            PHYSICAL STANDBY MAXIMUM PROTECTION

此时，如果主库有事务执行，是否可以执行成功呢？

主库事务：

SQL> delete t_m;

9 rows deleted

SQL> commit;

Commit complete

备库

SQL> select count(*) from t_m;

  COUNT(*)

----------

         9

事务操作并没有能够传递到备库上。当前的日志传输机制是正常的，如果我们切断了这种连接，处在最大保护模式下的Primary端如何。

[oracle@vLIFE-URE-OT-DB-STANDBY ~]$ lsnrctl stop

LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 21-OCT-2015 16:25:30

Copyright (c) 1991, 2013, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))

The command completed successfully

主库中立刻就有中断信息的显示：

***********************************************************************

Fatal NI connect error 12541, connecting to:

 (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=172.16.19.90)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=vlifesb)(CID=(PROGRAM=oracle)(HOST=vLIFE-URE-OT-DB-PRIMARY)(USER=oracle))))

  VERSION INFORMATION:

        TNS for Linux: Version 11.2.0.4.0 - Production

        TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production

  Time: 21-OCT-2015 16:25:41

  Tracing not turned on.

  Tns error struct:

    ns main err code: 12541

   

TNS-12541: TNS:no listener

    ns secondary err code: 12560

    nt main err code: 511

   

TNS-00511: No listener

    nt secondary err code: 111

    nt OS err code: 0

Error 12541 received logging on to the standby

Check whether the listener is up and running.

PING[ARC2]: Heartbeat failed to connect to standby 'vlifesb'. Error is 12541.

此时，我们在Primary上进行事务操作。

SQL> insert into t_m select * from dba_objects where rownum<100;

99 rows inserted

SQL> commit;

Commit complete

SQL> select group#, sequence#, status from v$log;

    GROUP#  SEQUENCE# STATUS

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

         1         89 CURRENT

         2         87 INACTIVE

         3         88 INACTIVE

事务操作成功。如果我们尝试重新启动standby，是不被允许的。

SQL> SQL> shutdown immediate

ORA-01154: database busy. Open, close, mount, and dismount not allowed now

日志：

Wed Oct 21 16:34:41 2015

Attempt to shut down Standby Database

Standby Database operating in NO DATA LOSS mode

Detected primary database alive, shutdown primary first, shutdown aborted

但是，切换日志强制归档过程的时候，数据库立即发现Standby存在问题，停库。

SQL> alter system switch logfile;

alter system switch logfile

 

ORA-03113: 通信通道的文件结尾

进程 ID: 9478

会话 ID: 394 序列号: 33

Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED

LGWR: All standby destinations have failed

******************************************************

WARNING: All standby database destinations have failed

WARNING: Instance shutdown required to protect primary

******************************************************

LGWR (ospid: 30597): terminating the instance due to error 16098

Wed Oct 21 16:43:44 2015

System state dump requested by (instance=1, osid=30597 (LGWR)), summary=[abnormal instance termination].

System State dumped to trace file /u01/app/oracle/diag/rdbms/vlife/vlife/trace/vlife_diag_30587_20151021164344.trc

Dumping diagnostic data in directory=[cdmp_20151021164344], requested by (instance=1, osid=30597 (LGWR)), summary=[abnormal instance termination].

Instance terminated by LGWR, pid = 30597

此时，standby端日志信息：

--Standby端

Wed Oct 21 16:43:42 2015

Archived Log entry 85 added for thread 1 sequence 89 ID 0xfad4f44b dest 1:

Wed Oct 21 16:43:43 2015

Wed Oct 21 16:43:43 2015

RFS[20]: Possible network disconnect with primary databaseRFS[17]: Possible network disconnect with primary database

说明：在最大保护状态的时候，如果Primary发现备库传输日志有问题，出于保护的必要，就会自动停机。

下面可以进行操作恢复，备库首先恢复应用日志状态：

SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered

Wed Oct 21 16:46:19 2015

alter database recover managed standby database using current logfile disconnect from session

Attempt to start background Managed Standby Recovery process (vlifesb)

Wed Oct 21 16:46:19 2015

MRP0 started with pid=25, OS id=1495

MRP0: Background Managed Standby Recovery process started (vlifesb)

 started logmerger process

Wed Oct 21 16:46:24 2015

Managed Standby Recovery starting Real Time Apply

Parallel Media Recovery started with 4 slaves

Waiting for all non-current ORLs to be archived...

All non-current ORLs have been archived.

Media Recovery Log /u01/app/oracle/fast_recovery_area/VLIFESB/archivelog/2015_10_21/o1_mf_1_89_c2gn1ylm_.arc

Media Recovery Waiting for thread 1 sequence 90

Completed: alter database recover managed standby database using current logfile disconnect from session

注意，此时第二个事务对应数据表t_m的数据已经发生变化。这说明之前虽然已经停止监听活动，但是依赖之前的已经确立连接，还是将日志传输过去。

SQL> select count(*) from t_m;

  COUNT(*)

----------

        99

尝试启动主库：

[oracle@vLIFE-URE-OT-DB-PRIMARY trace]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.4.0 Production on Wed Oct 21 16:48:23 2015

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

SQL> conn / as sysdba

Connected to an idle instance.

SQL> startup

ORACLE instance started.

Total System Global Area 2471931904 bytes

Fixed Size                  2255752 bytes

Variable Size             738198648 bytes

Database Buffers         1711276032 bytes

Redo Buffers               20201472 bytes

Database mounted.

ORA-03113: end-of-file on communication channel

Process ID: 9617

Session ID: 580 Serial number: 5

Error 12541 received logging on to the standby

Check whether the listener is up and running.

LGWR: Error 12541 creating archivelog file 'vlifesb'

Crash Recovery Foreground: All standby destinations have failed

******************************************************

WARNING: All standby database destinations have failed

WARNING: Instance shutdown required to protect primary

******************************************************

USER (ospid: 9617): terminating the instance due to error 16098

System state dump requested by (instance=1, osid=9617), summary=[abnormal instance termination].

System State dumped to trace file /u01/app/oracle/diag/rdbms/vlife/vlife/trace/vlife_diag_9581_20151021164839.trc

Dumping diagnostic data in directory=[cdmp_20151021164839], requested by (instance=1, osid=9617), summary=[abnormal instance termination].

Instance terminated by USER, pid = 9617

在mount到open的过程中，启动被终止。这个是可以理解的，在Standby端，监听器没有启动。

[oracle@vLIFE-URE-OT-DB-STANDBY ~]$ lsnrctl start

LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 21-OCT-2015 16:50:20

Copyright (c) 1991, 2013, Oracle.  All rights reserved.

（篇幅原因，有省略……）

Service "vlifesb" has 1 instance(s).

  Instance "vlifesb", status UNKNOWN, has 1 handler(s) for this service...

The command completed successfully

此时，再次启动数据库主库，操作成功。

SQL> startup

ORACLE instance started.

Total System Global Area 2471931904 bytes

Fixed Size                  2255752 bytes

Variable Size             738198648 bytes

Database Buffers         1711276032 bytes

Redo Buffers               20201472 bytes

Database mounted.

Database opened.

最后，从最大保护“退化”到最大性能模式。

SQL> alter database set standby database to maximize performance

  2  ;

Database altered

SQL> select name, open_mode, database_role, protection_mode from v$database;

NAME      OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE

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

VLIFE     READ WRITE           PRIMARY          MAXIMUM PERFORMANCE

5、结论

Oracle DG的三种模式，是与归档日志传输机制紧密相关的。归档日志传输确定了保护模式的基础前提，通过alter database set操作定义了数据库行为，特别是主库工作行为。

---

---

About Me

............................................................................................................................... ● 本文作者：小麦苗，只专注于数据库的技术，更注重技术的运用 ● 本文在itpub（http://blog.itpub.net/26736162）、博客园（http://www.cnblogs.com/lhrbest）和个人微信公众号（xiaomaimiaolhr）上有同步更新 ● 本文itpub地址：http://blog.itpub.net/26736162/abstract/1/ ● 本文博客园地址：http://www.cnblogs.com/lhrbest ● 本文pdf版及小麦苗云盘地址：http://blog.itpub.net/26736162/viewspace-1624453/ ● 数据库笔试面试题库及解答：http://blog.itpub.net/26736162/viewspace-2134706/ ● QQ群：230161599     微信群：私聊 ● 联系我请加QQ好友(646634621)，注明添加缘由 ● 于 2017-06-02 09:00 ~ 2017-06-30 22:00 在魔都完成 ● 文章内容来源于小麦苗的学习笔记，部分整理自网络，若有侵权或不当之处还请谅解 ● 版权所有，欢迎分享本文，转载请保留出处 ............................................................................................................................... 拿起手机使用微信客户端扫描下边的左边图片来关注小麦苗的微信公众号：xiaomaimiaolhr，扫描右边的二维码加入小麦苗的QQ群，学习最实用的数据库技术。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26736162/viewspace-2141200/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/26736162/viewspace-2141200/