版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/xxzhaobb/article/details/82531058
RDMBS 12.2.0.1 ，
官方文档上，最大保护模式的说明如下：
Maximum protection is similar to maximum availability but provides an additional level
of data protection in the event of multiple failure events. Unlike maximum availability,
which allows the primary to continue processing if it is unable to receive
acknowledgement from a standby database, maximum protection shuts the primary
database down rather than allowing it to continue processing transactions that are
unprotected.
Because this data protection mode prioritizes data protection over primary database
availability, Oracle recommends that a minimum of two standby databases be used to
protect a primary database that runs in maximum protection mode to prevent a single
standby database failure from causing the primary database to shut down.
-- 以下为测试的过程
-- 修改主库的log_archive_dest_2 ，原来是async，修改为sync
alter system set log_archive_dest_2='SERVICE=nocdb_stdby SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=nocdb_stdby';-- 为了主备库切换顺利，备库上也修改为sync
alter system set log_archive_dest_2='SERVICE=nocdb SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=nocdb'-- 主库上执行切换保护模式
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;--切换完毕后，
SYS@nocdb>select protection_mode from v$database;
PROTECTION_MODE
----------------------------------------
MAXIMUM PROTECTION
SYS@nocdb>-- 测试，关闭备库
SYS@nocdb_stdby>shutdown immediate
ORA-01154: 数据库忙。现在不允许打开, 关闭, 装载和卸装
SYS@nocdb_stdby>archive log list
数据库日志模式 存档模式
自动存档 启用
存档终点 E:\archivelog\nocdb_stdby
最早的联机日志序列 0
下一个存档日志序列 0
当前日志序列 0
SYS@nocdb_stdby>shutdown immediate
ORA-01154: 数据库忙。现在不允许打开, 关闭, 装载和卸装
SYS@nocdb_stdby>-- 查看备库的alert log
2018-09-08T10:48:38.922723+08:00
Primary database is in MAXIMUM PROTECTION mode
Changing standby controlfile to MAXIMUM PROTECTION mode
2018-09-08T10:48:39.500848+08:00
Primary database is in MAXIMUM PROTECTION mode
Standby controlfile consistent with primary
Standby controlfile consistent with primary
RFS[5]: Assigned to RFS process (PID:1332)
RFS[5]: Selected log 5 for T-1.S-27 dbid 3226205934 branch 985794675
2018-09-08T10:48:40.532098+08:00
RFS[6]: Assigned to RFS process (PID:2004)
RFS[6]: Selected log 4 for T-1.S-26 dbid 3226205934 branch 985794675
2018-09-08T10:48:44.438348+08:00
Archived Log entry 28 added for T-1.S-26 ID 0xc04ce117 LAD:1
2018-09-08T10:50:50.088739+08:00
Using STANDBY_ARCHIVE_DEST parameter default value as E:\archivelog\nocdb_stdby
2018-09-08T10:50:50.166864+08:00
ALTER SYSTEM SET log_archive_dest_2='SERVICE=nocdb SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=nocdb' SCOPE=BOTH;
2018-09-08T10:52:10.760614+08:00
Attempt to shut down Standby Database
Standby Database operating in NO DATA LOSS mode
Detected primary database alive, shutdown primary first, shutdown aborted
2018-09-08T10:53:41.416864+08:00
Attempt to shut down Standby Database
Standby Database operating in NO DATA LOSS mode
Detected primary database alive, shutdown primary first, shutdown aborted-- 关闭掉主库，再关闭掉备库，是可以正常关闭的。
-- 启动主库，(此时备库没有启动)，主库是无法启动的
SYS@nocdb>select protection_mode from v$database;
PROTECTION_MODE
----------------------------------------
MAXIMUM PROTECTION
SYS@nocdb>shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SYS@nocdb>startup
ORACLE 例程已经启动。
Total System Global Area 1073741824 bytes
Fixed Size 8755392 bytes
Variable Size 675284800 bytes
Database Buffers 385875968 bytes
Redo Buffers 3825664 bytes
数据库装载完毕。
ORA-03113: 通信通道的文件结尾
进程 ID: 6380
会话 ID: 27 序列号: 27386
SYS@nocdb>-- 查看主库的alert 日志：
2018-09-08T15:59:41.776239+08:00
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
LGWR: Primary database is in MAXIMUM PROTECTION mode
LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR
2018-09-08T15:59:41.776239+08:00
ARC0: Becoming a 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
2018-09-08T15:59:41.791864+08:00
ARCH: STARTING ARCH PROCESSES
Starting background process ARC1
2018-09-08T15:59:41.791864+08:00
ARC1 started with pid=35, OS id=6004
Starting background process ARC2
2018-09-08T15:59:41.807489+08:00
ARC2 started with pid=36, OS id=6284
Starting background process ARC3
2018-09-08T15:59:41.823114+08:00
ARC3 started with pid=37, OS id=7040
ARC1: Archival started
ARC2: Archival started
ARC3: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
2018-09-08T15:59:42.776239+08:00
Error 1034 received logging on to the standby
2018-09-08T15:59:42.807489+08:00
Errors in file E:\APP\TEST\VIRTUAL\diag\rdbms\nocdb\nocdb\trace\nocdb_lgwr_5144.trc:
ORA-01034: ORACLE ???
2018-09-08T15:59:42.838739+08:00
LGWR: Error 1034 verifying archivelog destination LOG_ARCHIVE_DEST_2
2018-09-08T15:59:42.838739+08:00
Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
LGWR: Continuing...
LGWR: Minimum of 1 applicable standby database required
2018-09-08T15:59:42.838739+08:00
Errors in file E:\APP\TEST\VIRTUAL\diag\rdbms\nocdb\nocdb\trace\nocdb_lgwr_5144.trc:
ORA-16072: ???????????????
2018-09-08T15:59:42.854364+08:00
Errors in file E:\APP\TEST\VIRTUAL\diag\rdbms\nocdb\nocdb\trace\nocdb_ora_6380.trc:
ORA-16072: 闇€瑕佷竴涓鐢ㄦ暟鎹簱鐩爣鐨勬渶灏忓€?
2018-09-08T15:59:42.854364+08:00
USER (ospid: 6380): terminating the instance due to error 16072
ERROR: Unable to normalize symbol name for the following short stack (at offset 125):
dbgeGetAsyncActivForED()+939<-dbkif_record_dde_actions()+421<-ksuitm_opt()+2482<-ksuitm()+14<-kcfopd()+10758<-adbdrv_options..0()+38247<-adbdrv()+161<-opiexe()+36274<-opiosq0()+6886<-kpooprx()+546<-kpoal8()+1173<-opiodr()+1378<-ttcpip()+1368<-opitsk()+2474<-opiino()+1265<-opiodr()+1378<-opidrv()+1833<-sou2o()+112<-opimai_real()+499<-opimai()+231<-OracleThreadStart()+745<-0000000076C2652D<-0000000076D5C521
2018-09-08T15:59:42.885614+08:00
System state dump requested by (instance=1, osid=6380), summary=[abnormal instance termination].
System State dumped to trace file E:\APP\TEST\VIRTUAL\diag\rdbms\nocdb\nocdb\trace\nocdb_diag_5664_20180908155942.trc
2018-09-08T15:59:46.479364+08:00
Instance terminated by USER, pid = 6380-- 查看对应的trc文件
Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR
Subscribing to KSR Channel [id = 32]
success!
Indicating recv buffer for KSR Channel [id = 20]
success
Waiting for NSS2 (PID:6228) to initialize itself
*** 2018-09-08T15:59:42.666864+08:00
*** 2018-09-08 15:59:42.666864 4455 krsw.c
Netserver NSS2 (PID:6228) for mode SYNC has been re-initialized
Performing a channel reset to ignore previous responses
Connecting as publisher to KSR Channel [id = 20]
Successfully reused NSS2 (PID:6228) for dest nocdb_stdby mode SYNC ocis = 0x00000000114F9EF0
*** 2018-09-08 15:59:42.776239 12728 krsu.c
Making upidhs request to NSS2 (ocis 0x00000000114F9EF0). Begin time is <09/08/2018 15:59:40> and NET_TIMEOUT <30> seconds
NetServer (PID:6228)
*** 2018-09-08 15:59:42.776239 12861 krsu.c
upidhs done status 1034
*** 2018-09-08 15:59:42.776239 7207 krsu.c
upiahm connect done status is 1034
*** 2018-09-08 15:59:42.776239 4079 krsu.c
Error 1034 connecting to destination LOG_ARCHIVE_DEST_2 standby host 'nocdb_stdby'
RFS network connection lost at host 'nocdb_stdby' error 1034
*** 2018-09-08 15:59:42.776239 12728 krsu.c
No LNS exists (ocis 0x00000000114F9EF0) that requires a disconnect
*** 2018-09-08 15:59:42.807489 12728 krsu.c
No LNS exists (ocis 0x00000000114F9EF0) that requires a disconnect
Standby archivelog instance not available at host 'nocdb_stdby'
ORA-01034: ORACLE ???
*** 2018-09-08 15:59:42.838739 5634 krsh.c
LGWR: Error 1034 verifying archivelog destination LOG_ARCHIVE_DEST_2
*** 2018-09-08 15:59:42.838739 12728 krsu.c
No LNS exists (ocis 0x00000000114F9EF0) that requires a disconnect
*** 2018-09-08 15:59:42.838739 12728 krsu.c
No LNS exists (ocis 0x00000000114F9EF0) that requires a disconnect
Continuing...
Standby database verification failed:16072
ORA-16072: ???????????????-- 另一个trc 文件
*** 2018-09-08T15:59:42.854364+08:00
*** SESSION ID:(27.27386) 2018-09-08T15:59:42.854364+08:00
*** CLIENT ID:() 2018-09-08T15:59:42.854364+08:00
*** SERVICE NAME:() 2018-09-08T15:59:42.854364+08:00
*** MODULE NAME:(sqlplus.exe) 2018-09-08T15:59:42.854364+08:00
*** ACTION NAME:() 2018-09-08T15:59:42.854364+08:00
*** CLIENT DRIVER:(SQL*PLUS) 2018-09-08T15:59:42.854364+08:00
ORA-16072: 需要一个备用数据库目标的最小值
2018-09-08 15:59:42.850 :kjzduptcctx(): Notifying DIAG for crash event
----- Abridged Call Stack Trace -----
ksedsts()+390<-kjzdssdmp()+249<-kjzduptcctx()+1008<-kjzdicrshnfy()+1297<-ksuitm_opt()+2192<-ksuitm()+14<-kcfopd()+10758<-adbdrv_options..0()+38247<-adbdrv()+161<-opiexe()+36274<-opiosq0()+6886<-kpooprx()+546<-kpoal8()+1173<-opiodr()+1378<-ttcpip()+1368<-opitsk()+2474
<-opiino()+1265<-opiodr()+1378<-opidrv()+1833<-sou2o()+112
----- End of Abridged Call Stack Trace -----
*** 2018-09-08T15:59:42.854364+08:00
USER (ospid: 6380): terminating the instance due to error 16072
C:\Users\zhao-pc>oerr ora 16072
16072, 00000, "a minimum of one standby database destination is required"
// *Cause: No standby database archive log destinations were specified.
// *Action: Specify a standby archive log destination in the initialization
// parameter file.
C:\Users\zhao-pc>-- 正常启动主备库，然后模拟备库掉电。备库关闭，主库刚开始正常运行，只是alert log中会报错，提示找不到备库。
经过一段时间的报错及挣扎，主库shutdown。
--alert log 如下
Error 1034 received logging on to the standby
2018-09-08T16:54:51.223504+08:00
LGWR: Error 1034 attaching to RFS for reconnect
2018-09-08T16:54:56.411004+08:00
Error 1034 received logging on to the standby
2018-09-08T16:54:56.411004+08:00
LGWR: Error 1034 attaching to RFS for reconnect
2018-09-08T16:54:56.411004+08:00
Errors in file E:\APP\TEST\VIRTUAL\diag\rdbms\nocdb\nocdb\trace\nocdb_lgwr_2668.trc:
ORA-01092: ORACLE 瀹炰緥缁堟銆傚己鍒舵柇寮€杩炴帴
Error 1092 for archive log file 3 to 'nocdb_stdby'
2018-09-08T16:54:56.426629+08:00
Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
LGWR: All standby destinations have failed
******************************************************
WARN: All standby database destinations have failed
WARN: Instance shutdown required to protect primary
******************************************************
LGWR (ospid: 2668): terminating the instance due to error 16098
2018-09-08T16:54:56.629754+08:00
System state dump requested by (instance=1, osid=2668 (LGWR)), summary=[abnormal instance termination].
System State dumped to trace file E:\APP\TEST\VIRTUAL\diag\rdbms\nocdb\nocdb\trace\nocdb_diag_6088_20180908165456.trc
2018-09-08T16:55:11.223504+08:00
Instance terminated by LGWR, pid = 2668END