聊聊Dataguard的三种保护模式实验（下）

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操作定义了数据库行为，特别是主库工作行为。

转：http://blog.itpub.net/17203031/viewspace-1826717/