Oracle DG —— 可更新的从库 Snapshot Standby Database

一、 简介

1. 特点

我们知道，无论是Physical还是Logical Standby，都只能从主库同步数据，从库都是只读的，而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是可写的从库，它通过Physical Standby通过convert操作转变而来。

Snapshot Standby会接收主库发送的归档和redo数据，但不进行应用。当转换回Physical Standby后，会从之前的转换点开始重新应用日志，直到追平同步，并且之前对Snapshot Standby执行的写操作会全部丢失。

 

2. 用途与限制

根据前面的特点，如果需要一个临时的、与主库相同的、可写的测试环境，可以考虑将物理从库转为Snapshot Standby，待测试完成后可以将其转回物理从库，不用重搭，日志能自动应用直至追平。

缺点也同样很明显，只接收不应用日志注定了对于负载较大的主库，Snapshot Standby只能是一个短时存在的测试环境。如果存在时间过长，一是从库归档日志无法删除迅速消耗磁盘空间，二是后面转回物理从库日志应用可能需要花费很长时间。

另外Snapshot Standby是不能作为Switchover和Failover目标库的，安全起见，起码要一主两从，拿其中一个从库转为Snapshot Standby。

 

二、 Physical Standby转为Snapshot Standby

1. 操作步骤

以下测试在11.2.0.4版本执行。操作相当简单，停mrp进程，重启从库到mount状态，执行转换即可。

alter database recover managed standby database cancel;
shutdown immediate

startup mount
--进行convert操作
alter database convert to snapshot standby;
Database altered.

alter database open;
Database altered.

如果没有停mrp进程直接执行，会遇到以下报错

alter database convert to snapshot standby;

ORA-38784: 无法创建还原点 'SNAPSHOT_STANDBY_REQUIRED_10/22/2015 10:59:37'??
ORA-01153: 激活了不兼容的介质恢复

结束之后，可以看到状态变化为Snapshot Standby。

select open_mode, database_role, protection_mode from v$database;

OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE
-------------------- ---------------- --------------------
MOUNTED              SNAPSHOT STANDBY MAXIMUM PERFORMANCE

 

2. convert操作原理

我们可以通过alert日志看看convert操作到底干了什么

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

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

概括一下大概执行了以下操作：

• 创建guaranteed 的闪回还原点
• 传输剩余的Standby Redo Log日志信息

• resetlog，清理Standby端的online redolog日志组（相当于执行基于SCN的恢复），新增incarnation

 

三、 Snapshot Standby测试

1. 观察归档日志情况

主库日志情况

select group#, sequence#, archived, status from v$log;

    GROUP#  SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
         1         98 YES      INACTIVE
         2         99 NO       CURRENT
         3         97 YES      INACTIVE 

select recid,sequence#, archived, applied from v$archived_log where name='vlifesb' and sequence#>=95;

     RECID  SEQUENCE# ARCHIVED APPLIED
---------- ---------- -------- ---------
       132         95 YES      YES
       134         96 YES      YES
       136         97 YES      NO   <--- 日志未应用
       138         98 YES      NO   <--- 日志未应用

可以看到，发送到vlifesb端的归档日志是连续的，没有发生中断现象。但是97、98号日志没有进行apply。符合我们之前说的，切换之后，Snapshot Standby接收主库日志但不应用。

再看看Snapshot Standby日志情况

select group#, sequence#, archived, status from v$log;

    GROUP#  SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
         1          1 NO       CURRENT
         3          0 YES      UNUSED
         2          0 YES      UNUSED

select recid,sequence#, archived, applied from v$archived_log where recid>=95;

     RECID  SEQUENCE# ARCHIVED APPLIED
---------- ---------- -------- ---------
        91         95 YES      YES
        92         96 YES      YES
        93         97 YES      NO
        94         98 YES      NO
        95         99 YES      NO
        96        100 YES      NO
        97        101 YES      NO

select * from v$standby_log;

GROUP# DBID                                        THREAD#  SEQUENCE#      BYTES  BLOCKSIZE       USED ARCHIVED STATUS     FIRST_CHANGE# FIRST_TIME  NEXT_CHANGE# NEXT_TIME   LAST_CHANGE# LAST_TIME
---------- ---------------------------------------- ---------- ---------- ---------- ---------- ---------- -------- ---------- ------------- ----------- ------------ ----------- ------------ -----------

         4 4207470439                                        1        102  104857600        512      80896 YES      ACTIVE           1794468 2015/10/22                                1794623 2015/10/22

         5 UNASSIGNED                                        1          0  104857600        512          0 NO       UNASSIGNED                                                                

         6 UNASSIGNED                                        0          0  104857600        512          0 YES      UNASSIGNED                                 

在Standby端，我们看到两套体系。从主库传来的归档日志通过在Archived Log中积累，只是没有被Apply。同时，online redolog体系中，原有的sequence系列被打乱了，从1开始重新计数，符合alert日志中看到的resetlog的特点。

 

2. Snapshot Standby写操作测试

• DDL与DML

create table t_sn as select * from dba_objects;
Table created

select count(*) from t_sn;

COUNT(*)
----------
86280

• 日志切换

alter system switch logfile;
alter system switch logfile;
alter system switch logfile;

select group#, sequence#, archived, status from v$log;

    GROUP#  SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ----------------
         1          4 YES      INACTIVE
         2          5 NO       CURRENT
         3          3 YES      INACTIVE

SQL> select recid,sequence#, archived, applied from v$archived_log where recid>=95;

     RECID  SEQUENCE# ARCHIVED APPLIED
---------- ---------- -------- ---------
        91         95 YES      YES
        92         96 YES      YES
        93         97 YES      NO
        94         98 YES      NO
        95         99 YES      NO
        96        100 YES      NO
        97        101 YES      NO
        98          1 YES      NO    <---- 注意序号变成了从1开始
        99          2 YES      NO
       100          3 YES      NO
       101          4 YES      NO

Primary传递过来的归档，以及Snapshot自身生成的新incarnation的归档同时存在。

 

四、 Snapshot Standby恢复回Physical Standby

1. 操作步骤

操作也很简单，启动到mount状态，convert，关闭数据库再正常startup，启动mrp进程即可。

shutdown immediate

startup mount
alter database convert to physical standby;

shutdown immediate
startup
alter database recover managed standby database using current logfile disconnect from session;

select open_mode, database_role from v$database;

DATABASE_ROLE
----------------
PHYSICAL STANDBY

2. convert操作原理

• 启动mrp进程之前的alert日志

Thu Oct 22 11:21:09 2015

alter database convert to physical standby

ALTER DATABASE CONVERT TO PHYSICAL STANDBY (vlifesb)

Killing 3 processes with pids 7474,7461,7463 (all RFS) in order to disallow current and future RFS connections. Requested by OS process 7457

Flashback Restore Start

Flashback Restore Complete

Drop guaranteed restore point

Guaranteed restore point  dropped

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/VLIFESB/flashback/o1_mf_c27f0mj2_.flb

Clearing standby activation ID 4208505925 (0xfad8b445)

The primary database controlfile was created using the 'MAXLOGFILES 16' clause. –重建control file

There is space for up to 13 standby redo logfiles

Use the following SQL commands on the standby database to create standby redo logfiles that match the primary database: -- 重建STANDBY LOGFILE

ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;

ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;

ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;

ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;

Shutting down archive processes

Archiving is disabled

Thu Oct 22 11:21:12 2015

ARCH shutting down

Thu Oct 22 11:21:12 2015

ARCH shutting down

Thu Oct 22 11:21:12 2015

ARCH shutting down

ARC3: Archival stopped

Thu Oct 22 11:21:12 2015

ARCH shutting downARC2: Archival stopped

ARC1: Archival stopped
ARC0: Archival stopped
Completed: alter database convert to physical standby

可以看到Oracle实际上在进行flashback操作，恢复控制文件和清理日志操作，并且会将数据库关到nomount状态，因此切换回去之后，我们需要关闭并重新正常启动数据库。

• 启动mrp进程之前的alert日志

Thu Oct 22 11:28:08 2015

alter database recover managed standby database using current logfile disconnect from session

Attempt to start background Managed Standby Recovery process (vlifesb)

Thu Oct 22 11:28:08 2015

MRP0 started with pid=30, OS id=7593

MRP0: Background Managed Standby Recovery process started (vlifesb)

 started logmerger process

Thu Oct 22 11:28:13 2015

Managed Standby Recovery starting Real Time Apply

Parallel Media Recovery started with 4 slaves

Waiting for all non-current ORLs to be archived...

All non-current ORLs have been archived.

Clearing online redo logfile 1 /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_1_c261g1mo_.log

Clearing online log 1 of thread 1 sequence number 104

Clearing online redo logfile 1 complete

Clearing online redo logfile 2 /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_2_c261g2d0_.log

Clearing online log 2 of thread 1 sequence number 5

Clearing online redo logfile 2 complete

Clearing online redo logfile 3 /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_3_c261g34d_.log

Clearing online log 3 of thread 1 sequence number 103

Completed: alter database recover managed standby database using current logfile disconnect from session

Clearing online redo logfile 3 complete

Media Recovery Log /u01/app/oracle/fast_recovery_area/VLIFESB/archivelog/2015_10_22/o1_mf_1_97_c2jnsh3g_.arc

Media Recovery Log /u01/app/oracle/fast_recovery_area/VLIFESB/archivelog/2015_10_22/o1_mf_1_98_c2jnvbw6_.arc

Media Recovery Log /u01/app/oracle/fast_recovery_area/VLIFESB/archivelog/2015_10_22/o1_mf_1_99_c2jo0hdc_.arc

Media Recovery Log /u01/app/oracle/fast_recovery_area/VLIFESB/archivelog/2015_10_22/o1_mf_1_100_c2jo0jjm_.arc

Media Recovery Log /u01/app/oracle/fast_recovery_area/VLIFESB/archivelog/2015_10_22/o1_mf_1_101_c2jo0kky_.arc

Media Recovery Log /u01/app/oracle/fast_recovery_area/VLIFESB/archivelog/2015_10_22/o1_mf_1_102_c2jod77o_.arc

Media Recovery Log /u01/app/oracle/fast_recovery_area/VLIFESB/archivelog/2015_10_22/o1_mf_1_103_c2joqhh0_.arc

Media Recovery Waiting for thread 1 sequence 104 (in transit)

Recovery of Online Redo Log: Thread 1 Group 4 Seq 104 Reading mem 0

  Mem# 0: /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_4_c265gc9q_.log

  Mem# 1: /u01/app/oracle/fast_recovery_area/VLIFESB/onlinelog/o1_mf_4_c265gcfk_.log

主要在清理redolog，同时应用日志，追平主库

select recid,sequence#, archived, applied from v$archived_log where recid>=95;

     RECID  SEQUENCE# ARCHIVED APPLIED
---------- ---------- -------- ---------
        91         95 YES      YES
        92         96 YES      YES
        93         97 YES      YES  <--- 都变为已应用
        94         98 YES      YES
        95         99 YES      YES
        96        100 YES      YES
        97        101 YES      YES
        98          1 YES      NO   <--- 跳过Snapshot Standby时期归档
        99          2 YES      NO
       100          3 YES      NO
       101          4 YES      NO
       102        102 YES      YES
       103        103 YES      IN-MEMORY

 

参考

http://blog.itpub.net/17203031/viewspace-1815636/

http://blog.itpub.net/17203031/viewspace-1816341/