Snapshot Standby Database
A snapshot standby database is a fully updatable standby database. A snapshot standby database receives and archives, but does not apply, redo data from a primary database. Redo data received from the primary database is applied when a snapshot standby database is converted back into a physical standby database, after discarding all local updates to the snapshot standby database.
A snapshot standby database typically diverges from its primary database over time because redo data from the primary database is not applied as it is received. Local updates to the snapshot standby database will cause additional divergence. The data in the primary database is fully protected however, because a snapshot standby can be converted back into a physical standby database at any time, and the redo data received from the primary will then be applied.
A snapshot standby database provides disaster recovery and data protection benefits that are similar to those of a physical standby database. Snapshot standby databases are best used in scenarios where the benefit of having a temporary, updatable snapshot of the primary database justifies increased time to recover from primary database failures.
当前环境信息
主库:两节点RAC11.2.0.4+ASM
备库:单实例11.2.0.4+本地文件系统
当前主备库状态信息
[oracle@pccb1 ~]$ dgmgrl sys/oracle DGMGRL for Linux: Version 11.2.0.4.0 - 64bit Production Copyright (c) 2000, 2009, Oracle. All rights reserved. Welcome to DGMGRL, type "help" for information. Connected. DGMGRL> show configuration; Configuration - dg_pccb Protection Mode: MaxPerformance Databases: pccb - Primary database pccbdg - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
将Physical Standby转化为Snapshot Standby
DGMGRL> help convert Converts a database from one type to another Syntax: CONVERT DATABASE <database name> TO {SNAPSHOT STANDBY|PHYSICAL STANDBY}; DGMGRL> convert database pccbdg to snapshot standby; Converting database "pccbdg" to a Snapshot Standby database, please wait... Database "pccbdg" converted successfully DGMGRL> show configuration; Configuration - dg_pccb Protection Mode: MaxPerformance Databases: pccb - Primary database pccbdg - Snapshot standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS DGMGRL>
Standby database alert
2017-03-17 07:54:25.595000 +08:00 Archived Log entry 111 added for thread 2 sequence 657 ID 0x71a0901 dest 1: 2017-03-17 08:08:36.933000 +08:00 RFS[9]: Selected log 8 for thread 1 sequence 684 dbid 119141633 branch 930070081 Media Recovery Waiting for thread 1 sequence 684 (in transit) Recovery of Online Redo Log: Thread 1 Group 8 Seq 684 Reading mem 0 Mem# 0: /oradata/pccbdg/stdredo02.log 2017-03-17 08:08:40.220000 +08:00 Archived Log entry 112 added for thread 1 sequence 683 ID 0x71a0901 dest 1: 2017-03-17 09:26:06.162000 +08:00 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL MRP0: Background Media Recovery cancelled with status 16037 Errors in file /pccb/ordb/log/diag/rdbms/pccbdg/pccbdg/trace/pccbdg_pr00_10006.trc: ORA-16037: ????????????????????? Managed Standby Recovery not using Real Time Apply Recovery interrupted! Recovered data files to a consistent state at change 3159534075 MRP0: Background Media Recovery process shutdown (pccbdg) 2017-03-17 09:26:08.165000 +08:00 Managed Standby Recovery Canceled (pccbdg) Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL All dispatchers and shared servers shutdown CLOSE: killing server sessions. CLOSE: all sessions shutdown successfully. 2017-03-17 09:28:08.364000 +08:00 SMON: disabling cache recovery alter database convert to snapshot standby Starting background process RVWR RVWR started with pid=18, OS id=7964 2017-03-17 09:28:11.610000 +08:00 Allocated 15937344 bytes in shared pool for flashback generation buffer Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_03/17/2017 09:28:08 Killing 8 processes with pids 9952,9955,9973,9977,9981,9983,10103,9987 (all RFS) in order to disallow current and future RFS connections. Requested by OS process 9946 2017-03-17 09:28:12.705000 +08:00 idle dispatcher 'D000' terminated, pid = (17, 1) 2017-03-17 09:28:13.719000 +08:00 Begin: Standby Redo Logfile archival End: Standby Redo Logfile archival RESETLOGS after incomplete recovery UNTIL CHANGE 3159534075 Resetting resetlogs activation ID 119146753 (0x71a0901) Online log /oradata/pccbdg/redo01.log: Thread 1 Group 1 was previously cleared Online log /oradata/pccbdg/redo02.log: Thread 1 Group 2 was previously cleared Online log /oradata/pccbdg/redo03.log: Thread 1 Group 3 was previously cleared Online log /oradata/pccbdg/redo04.log: Thread 2 Group 4 was previously cleared Online log /oradata/pccbdg/redo05.log: Thread 2 Group 5 was previously cleared Online log /oradata/pccbdg/redo06.log: Thread 2 Group 6 was previously cleared Standby became primary SCN: 3159534073 Setting recovery target incarnation to 2 AUDIT_TRAIL initialization parameter is changed back to its original value as specified in the parameter file. CONVERT TO SNAPSHOT STANDBY: Complete - Database mounted as snapshot standby Completed: alter database convert to snapshot standby 2017-03-17 09:28:15.163000 +08:00 ALTER DATABASE OPEN Data Guard Broker initializing... Data Guard Broker initialization complete Assigning activation ID 127286592 (0x7963d40) Thread 1 opened at log sequence 1 Current log# 1 seq# 1 mem# 0: /oradata/pccbdg/redo01.log Successful open of redo thread 1 ARC6: Becoming the 'no SRL' ARCH MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set ARC7: Becoming the 'no SRL' ARCH SMON: enabling cache recovery [9946] Successfully onlined Undo Tablespace 2. Undo initialization finished serial:0 start:746248684 end:746248894 diff:210 (2 seconds) Dictionary check beginning Dictionary check complete Verifying file header compatibility for 11g tablespace encryption.. Verifying 11g file header compatibility for tablespace encryption completed SMON: enabling tx recovery Database Characterset is ZHS16GBK 2017-03-17 09:28:16.255000 +08:00 No Resource Manager plan active Starting background process SMCO SMCO started with pid=33, OS id=7972 2017-03-17 09:28:17.568000 +08:00 Redo thread 2 internally disabled at seq 1 (CKPT) ARC2: Becoming the 'no SRL' ARCH ARC2: Archiving disabled thread 2 sequence 1 Archived Log entry 113 added for thread 2 sequence 1 ID 0x0 dest 1: ARC3: Becoming the 'no SRL' ARCH Starting background process QMNC QMNC started with pid=34, OS id=7974 LOGSTDBY: Validating controlfile with logical metadata LOGSTDBY: Validation complete 2017-03-17 09:28:19.797000 +08:00 Completed: ALTER DATABASE OPEN RFS[11]: Assigned to RFS process 7996 RFS[11]: Selected log 7 for thread 1 sequence 685 dbid 119141633 branch 930070081 RFS[12]: Assigned to RFS process 7998 RFS[12]: Selected log 8 for thread 1 sequence 684 dbid 119141633 branch 930070081 RFS[13]: Assigned to RFS process 8000 RFS[13]: Selected log 11 for thread 2 sequence 658 dbid 119141633 branch 930070081 RFS[14]: Assigned to RFS process 8004 RFS[14]: Selected log 12 for thread 2 sequence 659 dbid 119141633 branch 930070081 Starting background process CJQ0 CJQ0 started with pid=46, OS id=8006 2017-03-17 09:28:21.060000 +08:00 Active Session History (ASH) performed an emergency flush. This may mean that ASH is undersized. If emergency flushes are a recurring issue, you may consider increasing ASH size by setting the value of _ASH_SIZE to a sufficiently large value. Currently, ASH size is 8388608 bytes. Both ASH size and the total number of emergency flushes since instance startup can be monitored by running the following query: select total_size,awr_flush_emergency_count from v$ash_info; ARC4: Becoming the 'no SRL' ARCH 2017-03-17 09:28:22.839000 +08:00 Archived Log entry 114 added for thread 2 sequence 658 ID 0x71a0901 dest 1: 2017-03-17 09:28:24.448000 +08:00 ARC5: Becoming the 'no SRL' ARCH 2017-03-17 09:28:25.431000 +08:00 Archived Log entry 115 added for thread 1 sequence 684 ID 0x71a0901 dest 1: adrci>
注意以下节点
A.备库处于mount/read only/read only with apply等状态,所以备库自身不会产生redo日志
B.将Physical Standby转化为Snapshot Standby,可以看到是在备库上创建了一担保还原点(guaranteed restore point),与启用不启用flashback database没有直接性的关系。转化之后,Snapshot Standby database为继续接受来自主库的日志
Reference
http://docs.oracle.com/database/121/SBYDB/manage_ps.htm#SBYDB4801