Data Guard的模式 - 最大保護模式

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 = 2668

END 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章