DataGuard Standby数据库类型

DG Standby数据库类型

================

分为三类： 物理Standby、 逻辑Standby和 快照standby

1．物理Standby

    物理Standby与Primary数据库完全一模一样，在物理数据库磁盘上具有主库相同架构的块， 通过REDO应用（属于块对块的应用）来维护物理Standby数据库 。

    通常在物理Standby没有执行REDO应用操作的时候，可以将物理Standby数据库以 READ ONLY模式 打开，如果数据库中指定了Flashback Area的话，甚至还可以被临时性的置为READ WRITE模式，操作完之后再通过Flashback Database特性恢复回READ WRITE前的状态，以便继续接收Primary端发送的REDO并应用。

    物理Standby通过REDO应用来保持与Primary数据库的一致性，所谓的REDO应用，实质是通过Oracle 的恢复机制，应用归档文件（或Standby Redo logs文件）中的REDO数据。恢复操作属于块对块的应用。如果正在执行REDO应用的操作，Oracle数据库就不能被Open。

     Oracle 11g版本中增强物理Standby的应用功能，在11g版本中，物理Standby可以在OPEN READ ONLY模式下继续接收和应用primaru库产生的REDO数据，这就极大地提升了物理Standby数据库的应用场合。

    如果以 READ WRITE模式 打开，那么Standby数据库将暂停从Primary数据库接收REDO数据，并且暂时失去灾难保护的功能。可用于 需要临时调试一些数据，但又不方便在正式库中操作时， 就可以临时将Standby数据库置为READ WRITE模式，操作完之后将数据库闪回到操作前的状态（闪回之后，Data Guard会自动同步，不需要重建物理Standby，注意：如果没有启动闪回，那就回不到READ WRITE前的状态了）。

物理Standby特点如下：

（1）灾难恢复及高可用性：提供了一个健全、高效的灾难恢复，以及高可用性的解决方案。更加易于管理switchover/failover角色转换及在更短的计划内或计划外停机时间。

（2）数据保护：物理Standby DG能够确保即使面对无法预料的灾害也能够不丢失数据。前面也提到物理Standby是基于块对块的复制，因此与对象、语句无关，Primary数据库上有什么，物理Standby数据库端也会有什么。

（3）分担Primary数据库压力：通过将一些备份任务、仅查询的需求转移到物理Standby数据库，可以有效节省Primary数据库的CPU及I/O资源。

（4）提升性能：物理Standby所使用的REDO应用技术使用最底层的恢复机制，这种机制能够绕过SQL级代码层，因此效率最高。

2．逻辑Standby

    逻辑Standby也要通过Primary数据库（或其备份，或其复制库，如物理Standby）创建，因此在创建之初与物理Standby数据库类似。不过由于逻辑Standby 通过SQL应用的方式应用REDO数据 ，因此逻辑Standby的物理文件结构，甚至数据的逻辑结构都可以与Primary不一致。

    逻辑Standby正常情况下是以 READ WRITE模式打开，用户可以在任何时候访问逻辑Standby数据库，就是说逻辑Standby是在OPEN状态执行SQL应用。

    由于SQL应用的自身特点，逻辑Standby对于某些数据类型及一些DDL/DML语句会有操作上的限制。可以在视图DBA_LOGSTDBY_UNSUPPORTED 中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。

逻辑Standby有下列一些特点：

除了上述物理Standby中提到的类似灾难恢复、高可用性及数据保护等特点之外还有：

（1）有效地利用备机的硬件资源：除灾难恢复外，逻辑Standby数据库还可用于其他业务需求。如通过在Standby数据库创建额外的索引、物化视图等提高查询性能并满足特定业务需要；又如创建新的SCHEMA（该SCHEMA在Primary数据库端并不存在），然后在这些SCHEMA中执行那些不适于在Primary数据库端执行的DDL或者DML操作等。

（2）分担Primary数据库压力：逻辑Standby数据库是在READ WRITE模式打开状态做同步的，这使得逻辑Standby数据库能够同时用于数据保护和报表操作，从而将主数据库从报表和查询任务中解脱出来，节约宝贵的 CPU和I/O资源。

（3）平滑升级：可以通过逻辑Standby来实现如跨平台、跨版本升级，为数据库打补丁等操作。

3.快照standby

 

    11g Dataguard Snapshot Standby数据库功能，可将备库置于打开读写状态，进行模拟生产环境主库中测试。当备库Snapshot standby任务完成后，可以切换回物理备库角色。在Snapshot Standby数据库状态下，备库是可以接受主库传过来的日志，但是不能够将Redo内容应用到备库中。等到从Snapshot Standby库切回到物理备库的状态下，才应用redo日志，从而实现主库和备库的数据一致性。

   Snapshot standby被使用在需要一个临时可更新物理standby的快照的场景，注意因为redo数据只会被快照standby数据库接收但是不会被应用，直到被转化为一个物理standby数据库，而从一个主库恢复的故障时间和需要被应用的redo数据的数据量成正比。

    值得一提的是这个功能 不需要开启主备库的闪回数据库功能 ，先前在这里存在误区,这个功能还是比较赞的，可以直接拿物理备库做下临时测试数据库！

在备库mounted状态上：

1. SQL> alter database recover managed standby database cancel;   取消Standby库的Redo应用
2. Database altered.  
3.  
4. SQL> select open_mode,database_role,db_unique_name,flashback_on from v$database;  
5.  
6. OPEN_MODE            DATABASE_ROLE    DB_UNIQUE_NAME       FLASHBACK_ON  
7. -------------------- ---------------- -------------------- ------------------  
8. READ ONLY            PHYSICAL STANDBY dg2                  NO  
9.  
10. SQL> shutdown immediate 
11. 
    
12. SQL> startup mount
13. 
    
14. SQL> alter database convert to snapshot standby ;
15. 
    
16. SQL> select open_mode,database_role,db_unique_name,flashback_on from v$database;
17.  
18. OPEN_MODE   DATABASE_ROLE        DB_UNIQUE_NAME    FLASHBACK_ON
19. ----------- -------------------- ----------------- --------------------------
20. MOUNTED     SNAPSHOT STANDBY     dg2               RESTORE POINT ONLY
21.  
22. SQL> alter database open;  

然后就可以对快照数据库进行写数据操作， 查看快照数据库，已经多了一个incarnation，日志序列号从1开始：

1. [oracle@dg2 ~]$ rman target /  
2. Recovery Manager: Release 11.2.0.3.0 - Production on Sat May 5 15:35:43 2012  
3. Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.  
4. connected to target database: DG (DBID=1694605607)  
5.  
6. RMAN> list incarnation;  
7.  
8. using target database control file instead of recovery catalog  
9.  
10. List of Database Incarnations  
11. DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time  
12. ------- ------- -------- ---------------- --- ---------- ----------  
13. 1       1       DG       1694605607       PARENT  1          2011-09-17-09:46:04  
14. 2       2       DG       1694605607       PARENT  995548     2012-04-22-12:43:25  
15. 3       3       DG       1694605607       CURRENT 1107152    2012-05-05-15:20:09