[大数据]Data Guard ----理论详解(一)

DataGuard是甲骨文推出的一种高可用性数据库方案，在Oracle 8i之前被称为Standby Database。从ORACLE9i开始，改成DATA GUARD。在这种模式中，开始支持三种不同的数据保护模式，并开始采用LGWR 对数据的传送而不是以往的ARCH，而且增加了一个新的后台进程叫DMON 监控数据的同步，在11g之前最多支持9个节点的同时复制。从Oracle 9.2.0开始，开始支持逻辑standby。

1.Data Guard

1.1 Primary Database

DG环境包含一个主库。 主库可以是单实例，也可以是RAC 集群。

1.2 Standby Databases

1.2.1 Physical standby database –物理standby

物理standby是对主库进行physically identical copy。 这是一种Media recovery，是基于block-for-block的恢复。在数据块级别进行恢复，这种方式没有数据类型的限制，可以保证两个数据库完全一致。这个同步的过程叫Redo Apply。
在Oracle 11g之前，standby 数据库只能在Mount 状态下进行恢复，也可以是打开，但只能已只读方式打开，并且打开时不能执行恢复操作。
到了11g，standby 可以启动到read-only状态并同步，这样standby 数据库就可以用来进行一些数据查询操作，提高数据库的利用率。

1.2.2 Logical standby database --逻辑standby

逻辑standby 的同步使用的是SQL Apply。 这种方式是先把主库传送过来的redo 信息转换成SQL 语句，然后在备库执行这些SQL 语句，最终实现同步。
因为是通过Logminer 技术，通过把日志内容还原成SQL 语句，然后SQL引擎执行这些语句，Logminer Standby不支持所有数据类型，可以在视图 DBA_LOGSTDBY_UNSUPPORTED 中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。

1.2.3 Snapshot Standby Database – 快照 standby

Snapshot standby database是建立在物理standby 的基础上的。如果我们想在standby库上做一些测试，因为主库我们不能动，我们可以在备库测。 那么我们就可以把这个standby 切换成snapshot standby。

切换语句如下：
SQL> alter database convert to snapshot standby;
切换之后，我们可以查看alert log，会发现里面有创建一个restore point:
"Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_xxx"
把snapshot standby 数据库打开，进行我们的测试。
SQL> alter database open;
测试完毕后，我们把数据库重启到mount 状态。
执行命令将数据库从snapshot状态切换到之前的状态，如物理standby或者逻辑standby。
SQL> alter database convert to physical standby;

1.3 Data Guard Services

DG 有三个Services：

• Redo Transport Services
  这个服务在主库上，用来把主库的redo 数据传到指定的归档路径上去。 这个传输过程是自动实现的。
• Apply Services
  这个服务器用在备库上，其用来应用redo data，已保持主备库数据的一致性。Redo data 可以通过归档日志来应用，如果启用了real-time apply，当数据写入到standby redo log后，就会直接进行apply，不需要先在备库进行归档切换操作。
• Role Transitions
  这个服务用来控制主备库角色的切换，可以使用switchover 或者failover进行。

1.3.1 Redo Transport Services

Redo transport services 执行如下工作：

1. 根据参数中的配置，把主库的redo data 传送到备库。
2. 管理gap的进程。
3. 自动检测备库上缺失或者损坏的归档文件，如果检测到就把这些归档日志重新发送一次。

1.3.2 Apply Services

Redo data 从主库传到备库并写入备库的standby redo log。 Apply services 会自动的在备库上应用这些redo data来维护主备库数据的一致性。 在11g中也可以已只读的方式访问备库。

• 物理standby 使用Redo apply

• 逻辑standby 使用SQL apply

1.3.3 Role Transitions

1. SWITCHOVER

switchover有计划的将一个physical standby database 转换成为primary database，这个过程可以保证无数据丢失，在完成后其它的standby数据库和原来的primary库还可以成为这个dataguard的standby role的一部分.

2. FAILOVER

Failover是真正出现严重系统故障，如数据库宕机、软硬件故障导致的Primary不能支持服务，从而进行的切换动作

1.4 DG 的保护模式

Data Guard 允许定义3钟数据保护模式，分别是最大保护Maximum Protection，最大可用Maximum Availability和 最大性能Maximum Performance

1.4.1 最大保护（Maximum Protection）

这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其REDO不仅被写入到本地的Online Redo logs，还要同时写入到Standby数据库的Standby Redo logs，并确认REDO数据至少在一个Standby数据库中可用（如果有多个的话），然后才会在Primary数据库上提交。
使用这种方式要求Standby Database 必须配置Standby Redo Log，而Primary Database必须使用LGWR，SYNC，AFFIRM 方式归档到Standby Database.

1.4.2 最高可用性（Maximum availability）

这种模式在不影响Primary数据库可用前提下，提供最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求本地事务在提交前必须至少写入一台Standby数据库的Standby Redologs中，不过与最大保护模式不同。
如果出现故障导致Standby数据库无法访问，Primary数据库并不会被Shutdown(10G是Shutdown，11G是hang住)，而是自动转为最高性能模式，等Standby数据库恢复正常之后，Primary数据库又会自动转换成最高可用性模式。
这种方式要求Standby Database 必须配置Standby Redo Log，而Primary Database必须使用LGWR，SYNC，AFFIRM 方式归档到Standby Database.

1.4.3 最高性能（Maximum performance）

缺省模式 这种模式在不影响Primary数据库性能前提下，提供最高级别的数据保护策略。事务可以随时提交，当前Primary数据库的REDO数据至少需要写入一个Standby数据库，不过这种写入可以是不同步的。如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护，而仅对Primary数据库的性能有轻微影响。这也是创建Standby数据库时，系统的默认保护模式。
这种方式可以使用LGWR ASYNC 或者 ARCH 进程实现，Standby Database也不要求使用Standby Redo Log。

1.4.4 修改数据保护模式步骤

1. 关闭数据库，重启到Mount 状态，如果是RAC，需要关闭所有实例，然后只启动一个实例到mount状态。
2. 修改模式
   语法：
   ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};
   例：SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
3. 打开数据库
   SQL>alter database open;
4. 确认修改数据保护模式：
   SQL>select protection_mode,protection_level from v$database;

1.5 Data Guard Broker

💘关于DGBROKER详细介绍会在后面更文，先占个位💘

今天的文章就先到这里，后面继续更新Data Guard–理论详解（二）