Oracle DataGuard的保护模式 - 最大可用模式

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/xxzhaobb/article/details/82621734

RDBMS 12.2.0.1 

官方文档上关于最大可用模式的描述:

Maximum Availability
This protection mode provides the highest level of data protection that is possible
without compromising the availability of a primary database. Under normal operations,
transactions do not commit until all redo data needed to recover those transactions
has been written to the online redo log AND based on user configuration, one of the
following is true:
• redo has been received at the standby, I/O to the standby redo log has been
initiated, and acknowledgement sent back to primary
• redo has been received and written to standby redo log at the standby and
acknowledgement sent back to primary
If the primary does not receive acknowledgement from at least one synchronized
standby, then 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.
If the primary database fails, then this mode ensures no data loss occurs provided
there is at least one synchronized standby in the Oracle Data Guard configuration.
See "Performance Versus Protection in Maximum Availability Mode" for information
about the redo transport settings necessary to support Maximum Availability and
associated trade-offs.
Transactions on the primary are considered protected as soon as Oracle 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
Oracle 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. Oracle Data Guard signals any corruptions that are detected so that
immediate corrective action can be taken.

-- 查看库的模式

SYS@nocdb>select PROTECTION_MODE from v$database;

PROTECTION_MODE
----------------------------------------
MAXIMUM PROTECTION

SYS@nocdb>show parameter log_archive_dest_2

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
log_archive_dest_2                   string                 SERVICE=nocdb_stdby SYNC VALID
                                                            _FOR=(ONLINE_LOGFILES,PRIMARY_
                                                            ROLE) DB_UNIQUE_NAME=nocdb_std
                                                            by

SYS@nocdb_stdby>show parameter log_archive_dest_2

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
log_archive_dest_2                   string                 SERVICE=nocdb SYNC VALID_FOR=(
                                                            ONLINE_LOGFILES,PRIMARY_ROLE)
                                                            DB_UNIQUE_NAME=nocdb

-- 切换库的模式为最大可用模式

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;													
															
SYS@nocdb>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

数据库已更改。

SYS@nocdb>

-- 查看库的保护模式

SYS@nocdb>select PROTECTION_MODE from v$database;

PROTECTION_MODE
----------------------------------------
MAXIMUM AVAILABILITY

SYS@nocdb>

SYS@nocdb_stdby>select PROTECTION_MODE from v$database;

PROTECTION_MODE
----------------------------------------
MAXIMUM AVAILABILITY

SYS@nocdb_stdby>

-- 查看库的alert log 日志

2018-09-11T09:02:31.085389+08:00
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY
Completed: ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY
2018-09-11T09:02:31.601014+08:00
Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED
2018-09-11T09:02:32.944764+08:00
LGWR: Standby redo logfile selected to archive thread 1 sequence 31
LGWR: Standby redo logfile selected for thread 1 sequence 31 for destination LOG_ARCHIVE_DEST_2
2018-09-11T09:02:34.101014+08:00
Thread 1 advanced to log sequence 31 (LGWR switch)
  Current log# 2 seq# 31 mem# 0: E:\ORADATA\NOCDB\REDO02.LOG
2018-09-11T09:02:40.288514+08:00
Archived Log entry 46 added for T-1.S-30 ID 0xc04ce117 LAD:1

2018-09-11T09:02:32.288514+08:00
Changing standby controlfile to MAXIMUM AVAILABILITY mode
RFS[1]: Selected log 4 for T-1.S-31 dbid 3226205934 branch 985794675
2018-09-11T09:02:33.819764+08:00
Media Recovery Waiting for thread 1 sequence 31 (in transit)
2018-09-11T09:02:34.194764+08:00
Recovery of Online Redo Log: Thread 1 Group 4 Seq 31 Reading mem 0
  Mem# 0: E:\ORADATA\NOCDB_STDBY\STDBY_REDO04.LOG
2018-09-11T09:02:38.085389+08:00
Archived Log entry 32 added for T-1.S-30 ID 0xc04ce117 LAD:1

-- 测试,关闭备库

SYS@nocdb_stdby>shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SYS@nocdb_stdby>

-- 备库的alert log

2018-09-11T09:08:01.288514+08:00
Shutting down instance (immediate) (OS id: 1924)
Stopping background process SMCO
2018-09-11T09:08:02.335389+08:00
Shutting down instance: further logons disabled
Stopping background process MMNL
2018-09-11T09:08:03.351014+08:00
Stopping background process MMON
2018-09-11T09:08:04.351014+08:00
MRP0: Background Media Recovery cancelled with status 16037
2018-09-11T09:08:04.351014+08:00
Errors in file E:\APP\TEST\VIRTUAL\diag\rdbms\nocdb_stdby\nocdb_stdby\trace\nocdb_stdby_mrp0_1796.trc:
ORA-16037: 鐢ㄦ埛宸茶姹傚彇娑堝彈绠℃仮澶嶆搷浣?
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Recovered data files to a consistent state at change 2257943
2018-09-11T09:08:04.569764+08:00
Errors in file E:\APP\TEST\VIRTUAL\diag\rdbms\nocdb_stdby\nocdb_stdby\trace\nocdb_stdby_mrp0_1796.trc:
ORA-16037: 鐢ㄦ埛宸茶姹傚彇娑堝彈绠℃仮澶嶆搷浣?
2018-09-11T09:08:05.351014+08:00
License high water mark = 4
2018-09-11T09:08:05.538514+08:00
Dispatchers and shared servers shutdown
2018-09-11T09:08:18.366639+08:00
ALTER DATABASE CLOSE NORMAL
2018-09-11T09:08:18.366639+08:00
Stopping Emon pool
Stopping Emon pool
Completed: ALTER DATABASE CLOSE NORMAL
ALTER DATABASE DISMOUNT
Shutting down archive processes
2018-09-11T09:08:18.788514+08:00
TT00: Gap Manager exiting (PID:616)
2018-09-11T09:08:19.772889+08:00
Archiving is disabled
2018-09-11T09:08:19.772889+08:00
ARC2: ARCH shutting down
ARC2: Archival stopped
2018-09-11T09:08:19.804139+08:00
ARC3: ARCH shutting down
ARC3: Archival stopped
2018-09-11T09:08:19.804139+08:00
ARC1: ARCH shutting down
ARC1: Archival stopped
2018-09-11T09:08:19.819764+08:00
ARC0: ARCH shutting down
ARC0: Archival stopped
2018-09-11T09:08:21.991639+08:00
Completed: ALTER DATABASE DISMOUNT
2018-09-11T09:08:21.991639+08:00
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
JIT: pid 1372 requesting stop
2018-09-11T09:08:23.007264+08:00
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
2018-09-11T09:08:23.022889+08:00
Stopping background process VKTM
2018-09-11T09:08:23.069764+08:00
JIT: pid 1372 requesting stop
2018-09-11T09:08:27.272889+08:00
Instance shutdown complete (OS id: 1924)

-- 主库的alert log

2018-09-11T09:08:06.069764+08:00
LGWR: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (1089)
LGWR: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
2018-09-11T09:08:06.069764+08:00
Errors in file E:\APP\TEST\VIRTUAL\diag\rdbms\nocdb\nocdb\trace\nocdb_lgwr_1672.trc:
ORA-01089: 姝e湪鎵ц绔嬪嵆鍏抽棴瀹炰緥鎴栫珛鍗冲叧闂暟鎹簱鎿嶄綔 - 涓嶅厑璁歌繘琛屼换浣曟搷浣?
Error 1089 for archive log file 2 to 'nocdb_stdby'
2018-09-11T09:08:06.257264+08:00
Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
2018-09-11T09:08:07.616639+08:00
LGWR: Failed to archive log 2 thread 1 sequence 31 (1089)
LGWR: Error 1041 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'nocdb_stdby'
2018-09-11T09:08:07.741639+08:00
Thread 1 advanced to log sequence 32 (LGWR switch)
  Current log# 3 seq# 32 mem# 0: E:\ORADATA\NOCDB\REDO03.LOG
2018-09-11T09:08:08.085389+08:00
Archived Log entry 47 added for T-1.S-31 ID 0xc04ce117 LAD:1

--主库上的alert log 及trc内容 ,主库没有关闭,一直在运行

2018-09-11T09:02:40.288514+08:00
Archived Log entry 46 added for T-1.S-30 ID 0xc04ce117 LAD:1
2018-09-11T09:08:06.069764+08:00
LGWR: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (1089)
LGWR: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
2018-09-11T09:08:06.069764+08:00
Errors in file E:\APP\TEST\VIRTUAL\diag\rdbms\nocdb\nocdb\trace\nocdb_lgwr_1672.trc:
ORA-01089: 姝e湪鎵ц绔嬪嵆鍏抽棴瀹炰緥鎴栫珛鍗冲叧闂暟鎹簱鎿嶄綔 - 涓嶅厑璁歌繘琛屼换浣曟搷浣?
Error 1089 for archive log file 2 to 'nocdb_stdby'
2018-09-11T09:08:06.257264+08:00
Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
2018-09-11T09:08:07.616639+08:00
LGWR: Failed to archive log 2 thread 1 sequence 31 (1089)
LGWR: Error 1041 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'nocdb_stdby'
2018-09-11T09:08:07.741639+08:00
Thread 1 advanced to log sequence 32 (LGWR switch)
  Current log# 3 seq# 32 mem# 0: E:\ORADATA\NOCDB\REDO03.LOG
2018-09-11T09:08:08.085389+08:00
Archived Log entry 47 added for T-1.S-31 ID 0xc04ce117 LAD:1
2018-09-11T09:13:47.507264+08:00
Error 1034 received logging on to the standby
2018-09-11T09:18:47.929139+08:00
Error 1034 received logging on to the standby
2018-09-11T09:23:48.632264+08:00
Error 1034 received logging on to the standby
2018-09-11T09:28:49.351014+08:00
Error 1034 received logging on to the standby
2018-09-11T09:33:49.663514+08:00
Error 1034 received logging on to the standby
2018-09-11T09:38:50.257264+08:00
Error 1034 received logging on to the standby
2018-09-11T09:43:50.851014+08:00
Error 1034 received logging on to the standby
2018-09-11T09:48:51.194764+08:00
Error 1034 received logging on to the standby
2018-09-11T09:53:51.851014+08:00
Error 1034 received logging on to the standby
2018-09-11T09:58:52.210389+08:00
Error 1034 received logging on to the standby
2018-09-11T10:03:52.585389+08:00
Error 1034 received logging on to the standby
2018-09-11T10:08:53.116639+08:00
Error 1034 received logging on to the standby

Error 1041 detaching RFS from standby instance at host 'nocdb_stdby'
*** 2018-09-11 09:08:07.632264 12728 krsu.c
Making upidhs request to NSS2 (ocis 0x000000000191AC40). Begin time is <09/11/2018 09:08:05> and NET_TIMEOUT <30> seconds
NetServer (PID:1068)
*** 2018-09-11 09:08:07.632264 12861 krsu.c
  upidhs done status 1041
*** 2018-09-11 09:08:07.632264 5634 krsh.c
LGWR: Error 1041 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'nocdb_stdby'
krsl_redo_complete: ignoring detach error 1041
krsi_dst_fail_caller: Returning because destination already inactive
krsj_test_sync: Standby mount ID 1813792114 not found
*** 2018-09-11 09:08:07.679139 3119 krsl.c
No standby database destinations have been configured
as being archived by the LGWR process
This instance will operate at a reduced protection mode until
network connectivity to the standby databases is restored and
all archivelog gaps have been resolved.

启动备库后,主库上的alert log

Error 1034 received logging on to the standby
2018-09-11T10:12:14.022889+08:00
ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=MEMORY SID='*';
2018-09-11T10:12:14.726014+08:00
LGWR: Standby redo logfile selected for thread 1 sequence 33 for destination LOG_ARCHIVE_DEST_2
2018-09-11T10:12:15.022889+08:00
Thread 1 advanced to log sequence 33 (LGWR switch)
  Current log# 1 seq# 33 mem# 0: E:\ORADATA\NOCDB\REDO01.LOG
2018-09-11T10:12:16.960389+08:00
Archived Log entry 48 added for T-1.S-32 ID 0xc04ce117 LAD:1
2018-09-11T10:12:17.054139+08:00
ARC3: Standby redo logfile selected for thread 1 sequence 31 for destination LOG_ARCHIVE_DEST_2
2018-09-11T10:12:17.647889+08:00
Error 1033 received logging on to the standby
2018-09-11T10:12:17.647889+08:00
Errors in file E:\APP\TEST\VIRTUAL\diag\rdbms\nocdb\nocdb\trace\nocdb_arc1_1944.trc:
ORA-01033: ORACLE 姝e湪鍒濆鍖栨垨鍏抽棴
ARC1: FAL archive failed with error 1033.  See trace for details
FAL archive failed, archiver continuing
2018-09-11T10:12:17.835389+08:00
Errors in file E:\APP\TEST\VIRTUAL\diag\rdbms\nocdb\nocdb\trace\nocdb_arc1_1944.trc:
ORA-16055: 宸叉嫆缁?FAL 璇锋眰
2018-09-11T10:18:17.460389+08:00
LGWR: Standby redo logfile selected to archive thread 1 sequence 34
LGWR: Standby redo logfile selected for thread 1 sequence 34 for destination LOG_ARCHIVE_DEST_2
2018-09-11T10:18:17.554139+08:00
Thread 1 advanced to log sequence 34 (LGWR switch)
  Current log# 2 seq# 34 mem# 0: E:\ORADATA\NOCDB\REDO02.LOG
2018-09-11T10:18:18.226014+08:00
Archived Log entry 51 added for T-1.S-33 ID 0xc04ce117 LAD:1
2018-09-11T10:18:22.101014+08:00
Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED
LGWR: Standby redo logfile selected to archive thread 1 sequence 35
LGWR: Standby redo logfile selected for thread 1 sequence 35 for destination LOG_ARCHIVE_DEST_2
2018-09-11T10:18:23.226014+08:00
Thread 1 advanced to log sequence 35 (LGWR switch)
  Current log# 3 seq# 35 mem# 0: E:\ORADATA\NOCDB\REDO03.LOG
2018-09-11T10:18:23.647889+08:00
Archived Log entry 54 added for T-1.S-34 ID 0xc04ce117 LAD:1

END

猜你喜欢

转载自blog.csdn.net/xxzhaobb/article/details/82621734