Oracle 11g是Data Guard的重要里程碑版本。在11g中，Active DataGuard、Advanced Compression等特性大大丰富了Data Guard的功能和在实践领域应用的广度。其中，除了传统的Physical Standby和Logical Standby，11g推出了新的Standby类型——Snapshot Standby。
Standby的实质是“同步更新”，无论是Physical Standby还是Logical Standby，都是依照主库Primary的形式进行同步或者异步更新。Standby自身是不能有主动地更新动作的。所以，即使进入11g的Active Data guard，备库也只是可以进行只读操作动作，不能自我进行更新动作。
而Snapshot Standby的出现改变了这一点。在Oracle官方文档中，对这个特性的解释如下：
“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.”
简单的说，Snapshot Standby是一种特殊的Standby类型。它以某一个时点的Physical Standby作为基础，通过convert操作变成snapshot备库。该备库可以进行修改操作（增加、修改和删除）操作。当执行结束之后，可以重新回到Physical Standby角色。“失联”期间发生的所有update操作，都全部被取消掉。“失联”期间主库发生的修改动作，也会在应用apply日志的时候追赶上。
技术是面对应用场景的。Snapshot是针对什么样的需求特征呢？在实际环境，特别是应用开发、测试环境中，我们偶尔会需要一个临时性的测试环境。这个环境上进行一些临时性、可抛弃的测试。这个时候，就可以使用这个snapshot standby。
本篇通过一系列的实验，来演示Snapshot Standby的常用操作、工作特性和日志行为分析。
1、环境说明
笔者使用Oracle 11gR2进行测试，版本编号为11.2.0.4。当前Primary和Standby都已经搭建完成。
版本信息如下：
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE 11.2.0.4.0 Production
TNS for Linux: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 – Production
主库Primary信息：
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
SQL> select instance_name from v$instance;
INSTANCE_NAME
----------------
vlife
SQL> select group#, sequence#, archived, status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
1 95 YES INACTIVE
2 96 YES INACTIVE
3 97 NO CURRENT
SQL> select recid,sequence#, archived, applied from v$archived_log where name='vlifesb' and sequence#>90;
RECID SEQUENCE# ARCHIVED APPLIED
---------- ---------- -------- ---------
123 91 YES YES
126 92 YES YES
128 93 YES YES
130 94 YES YES
132 95 YES YES
134 96 YES NO
6 rows selected
当前保护模式是Maximum Protection模式，正在apply状态的日志编号是96。当前online redo log编号为97。
Standby端信息：
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 PERFORMANCE
SQL> select instance_name from v$instance;
INSTANCE_NAME
----------------
vlifesb
SQL> select group#, sequence#, archived, status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
1 95 YES CLEARING
2 96 YES CLEARING
3 97 YES CURRENT
SQL> select recid,sequence#, archived, applied from v$archived_log where sequence#>90;
RECID SEQUENCE# ARCHIVED APPLIED
---------- ---------- -------- ---------
87 91 YES YES
88 92 YES YES
89 93 YES YES
90 94 YES YES
91 95 YES YES
92 96 YES IN-MEMORY
6 rows selected
当前Standby端的Flashback Database开启。
SQL> select oldest_flashback_scn, oldest_flashback_time from v$flashback_database_log;
OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK_TIME
-------------------- ---------------------
1646229 2015/10/21 3:41:25
2、切换到Snapshot Standby
当前我们的vlifesb是physical standby类型，保护模式是默认的最大性能模式。这也就意味着两者之前是允许存在Gap的。切换Snapshot Standby，有两个限制前提条件：
首先，如果切换为Snapshot Standby，就不能在期间进行Switchover和Failover操作。如果需要使用操作，就需要先切换回Physical Standby才能实现。
其次，如果使用的保护模式是Maximum Protection模式，必须有其他的Standby与之相匹配。要不然就会出现由于日志传输引起的宕机情况。
当前Standby状态是只读Apply状态，这个时候需要终止Apply过程，并且切换回mount状态。否则是不允许进行convert动作的。
SQL> alter database convert to snapshot standby;
alter database convert to snapshot standby
ORA-38784: 无法创建还原点 'SNAPSHOT_STANDBY_REQUIRED_10/22/2015 10:59:37'??
ORA-01153: 激活了不兼容的介质恢复
重启数据库进入mount状态。
SQL> conn / as sysdba
Connected.
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
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.
进行convert切换动作。
SQL> alter database convert to snapshot standby;
Database altered.
此时standby端的alert log展示了动作。
Thu Oct 22 11:09:21 2015
alter database convert to snapshot standby
Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_10/22/2015 11:09:21 –创建出一个可用的flashback database restore point
Killing 3 processes with pids 7314,7318,7316 (all RFS) in order to disallow current and future RFS connections. Requested by OS process 7312
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
RESETLOGS after incomplete recovery UNTIL CHANGE 1794139
Resetting resetlogs activation ID 4208260171 (0xfad4f44b)
Online log /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_1_c261g1mo_.log: Thread 1 Group 1 was previously cleared
Online log /u01/app/oracle/fast_recovery_area/VLIFESB/onlinelog/o1_mf_1_c261g1pt_.log: Thread 1 Group 1 was previously cleared
Online log /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_2_c261g2d0_.log: Thread 1 Group 2 was previously cleared
Online log /u01/app/oracle/fast_recovery_area/VLIFESB/onlinelog/o1_mf_2_c261g2gl_.log: Thread 1 Group 2 was previously cleared
Online log /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_3_c261g34d_.log: Thread 1 Group 3 was previously cleared
Online log /u01/app/oracle/fast_recovery_area/VLIFESB/onlinelog/o1_mf_3_c261g36q_.log: Thread 1 Group 3 was previously cleared
Standby became primary SCN: 1794137
Thu Oct 22 11:09:23 2015
Setting recovery target incarnation to 3 –创建出一个新的朝代
CONVERT TO SNAPSHOT STANDBY: Complete - Database mounted as snapshot standby
Completed: alter database convert to snapshot standby
Thu Oct 22 11:09:30 2015
RFS[3]: Assigned to RFS process 7324
RFS[3]: Selected log 5 for thread 1 sequence 98 dbid -87496857 branch 892734889
Thu Oct 22 11:09:30 2015
ARC0: Becoming the 'no SRL' ARCH
Thu Oct 22 11:09:30 2015
RFS[4]: Assigned to RFS process 7326
RFS[4]: Selected log 4 for thread 1 sequence 99 dbid -87496857 branch 892734889
Archived Log entry 94 added for thread 1 sequence 98 ID 0xfad4f44b dest 1:
Thu Oct 22 11:09:54 2015
ARC2: Becoming the 'no SRL' ARCH
从日志上看，我们看到Oracle将普通Physical Standby切换到Snapshot Standby的过程，经过了如下步骤：
ü 创建出一个Flashback的恢复点；
ü 传输剩余的Standby Redo Log日志信息；
ü 清理Standby端的online redo log日志组；
ü 使用reset log方法，创建出新的朝代数据；
结束之后，可以看到Standby端的状态变化为Snapshot Standby。
SQL> select open_mode, database_role, protection_mode from v$database;
OPEN_MODE DATABASE_ROLE PROTECTION_MODE
-------------------- ---------------- --------------------
MOUNTED SNAPSHOT STANDBY MAXIMUM PERFORMANCE
转：http://blog.itpub.net/17203031/viewspace-1815636/