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的一部分.

  1. 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必须使用LGWRSYNCAFFIRM 方式归档到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必须使用LGWRSYNCAFFIRM 方式归档到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. 修改模式
  3. 语法:
  4. ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};
  5. 例:SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
  6. 打开数据库
  7. SQL>alter database open;
  8. 确认修改数据保护模式:
  9. SQL>select protection\_mode,protection\_level from v$database;

1.5 Data Guard Broker

关于DGBROKER详细介绍会在后面更文,先占个位??
今天的文章就先到这里,后面继续更新
oracle Data Guard 理论详解②

来源:https://blog.csdn.net/easonhyj/article/details/122806347

最后修改:2022 年 02 月 12 日
如果觉得我的文章对你有用,请随意赞赏