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 执行如下工作:
- 根据参数中的配置,把主库的redo data 传送到备库。
- 管理gap的进程。
- 自动检测备库上缺失或者损坏的归档文件,如果检测到就把这些归档日志重新发送一次。
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
- SWITCHOVER
switchover有计划的将一个physical standby database 转换成为primary database,这个过程可以保证无数据丢失,在完成后其它的standby数据库和原来的primary库还可以成为这个dataguard的standby role的一部分.
- 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 修改数据保护模式步骤
- 关闭数据库,重启到Mount 状态,如果是RAC,需要关闭所有实例,然后只启动一个实例到mount状态。
- 修改模式
- 语法:
- ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};
- 例:SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
- 打开数据库
- SQL>alter database open;
- 确认修改数据保护模式:
- SQL>select protection\_mode,protection\_level from v$database;
1.5 Data Guard Broker
关于DGBROKER
详细介绍会在后面更文,先占个位??
今天的文章就先到这里,后面继续更新
oracle Data Guard 理论详解②