DataGuard基本理论

最新推荐文章于 2022-11-23 15:02:24 发布

cpcmix6825

最新推荐文章于 2022-11-23 15:02:24 发布

阅读量103

点赞数

Data Guard概述

一个Data Guard 配置包含一个Primary 数据库和最多九个Standby 数据库。Primary 的创建就不说了，Standby 数据库初始可以通过primary 数据库的备份创建。一旦创建并配置成standby 后，Data Guard 负责传输primary数据库redo data 到standby 数据库，standby 数据库通过应用接收到的redo data 保持与primary 数据库的事务一致。

Data Guard的管理方式

命令行管理；

Data Guard broker提供的专用命令行界面（DGMGRL）；

OEM图形化管理界面；

Data Guard服务(Data Guard Services)

 REDO 传输服务(Redo Transport Services)

控制redo 数据的传输到一个或多个归档目的地。

 Log 应用服务(Log Apply Services)

应用redo 数据到standby 数据库，以保持与primary 数据库的事务一致。redo 数据即可以从standby 数据库的归档文件读取，也可直接应用standby redo log 文件(如果实时应用打开了的话)。

 角色转换服务(Role Transitions)

Dg 中只有两种角色：primary 和standby。所谓角色转换就是让数据库在这两个角色中切换，切换也分两种：switchover 和failover

switchover：转换primary 数据库与standby 数据库。switchover 可以确保不会丢失数据。

failover：当primary 数据库出现故障并且不能被及时恢复时，会调用failover 将一个standby 数据库转换为新的primary 数据库。在最大保护模式或最高可用性模式下，failover 可以保证不会丢失数据。

Data Guard的三种保护模式

最高可用性：

这种模式提供在不影响primary 数据库可用前提下最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求所有事务在提交前必须保障redo 数据至少在一个standby 数据库可用，不过与之不同的是，如果出现故障导入无法同时写入standby 数据库redo log，primary 数据库并不会shutdown，而是自动转为最高性能模式，等standby 数据库恢复正常之后，它又会再自动转换成最高可用性模式。

最大保护：

这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其redo 不仅被写入到本地的online redo log，还要同时提交到standby 数据库的standby redo log，并确认redo 数据至少在一个standby 数据库可用(如果有多个的话)，然后才会在primary 数据库上提交。如果出现了什么故障导致standby数据库不可用的话，primary 数据库会被shutdown。

最大性能：

这种模式提供在不影响primary 数据库性能前提下最高级别的数据保护策略。事务可以随时提交，当前primary 数据库的redo 数据也需要至少写入一个standby 数据库，不过这种写入可以是不同步的。如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护而仅对primary 数据库有轻微的性能影响。

物理和逻辑Data Guard的比较

物理DataGuard	逻辑DataGuard
Standby数据库和Primary数据库完全一致	Standby数据库和Primary数据库不完全一致
通过Oracle的介质恢复机制应用redo文件	通过Oracle的SQL方式来应用redo文件
应用redo时Standby数据库不能被打开； Read-only模式时可以在Standby中执行查询和接收redo文件，但不能应用redo文件； Read-write模式时standby中停止接收redo文件，保护作用失去；	没有访问模式的区别，随时可以以read-write模式访问standby数据库且随时都接收和应用redo文件
没有数据类型或其他的限制	逻辑standby 对于某些数据类型以及一些ddl,dml 会有操作上的限制

Data Guard的软硬件需求

硬件及操作系统需求

u 同一个Data Gurid 配置中的所有oracle 数据库必须运行于相同的平台。比如inter 架构下的32 位linux 系统可以与inter 架构下的32 位linux 系统组成一组Data Guard。另外，如果服务器都运行于32 位的话，64 位HP-UX 也可以与32 位HP-UX 组成一组Data Guard。

u 不同服务器的硬件配置可以不同，比如cpu 啦，内存啦，存储设备啦，但是必须确保standby 数据库服务器有足够的磁盘空间用来接收及应用redo 数据。

u primary 数据库和standby 数据库的操作系统必须一致，不过操作系统版本可以略有差异，比如(linux as4&linux as5)，primary 数据库和standby 数据库的目录路径也可以不同。

2、软件需求

u Data Guard 是Oracle 企业版的一个特性，明白了吧，标准版是不支持地。

u 通过Data Guard 的SQL 应用，可以实现滚动升级服务器数据库版本(要求升级前数据库版本不低于10.1.0.3)。

u 同一个Data Guard 配置中所有数据库初始化参数：COMPATIBLE 的值必须相同。

u Primary 数据库必须运行于归档模式，并且务必确保在primary 数据库上打开FORCE LOGGING，以避免用户通过nologging 等方式避免写redo 造成对应的操作无法传输到standby 数据库。

u Primary 和standby 数据库均可应用于单实例或RAC 架构下，并且同一个data guard 配置可以混合使用逻辑standby 和物理standby。

u Primary 和standby 数据库可以在同一台服务器，但需要注意各自的数据文件存放目录，避免重写或覆盖。

u 使用具有sysdba 系统权限的用户管理primary 和standby 数据库。

u 建议数据库必须采用相同的存储架构。比如存储采用ASM/OMF 的话，那不分primarty 或是standby也都需要采用ASM/OMF。

u 注意各服务器的时间设置，不要因为时区/时间设置的不一置造成同步上的。

Oracle Data Guard中的redo logs

在Oracle Data Guard中包含两类redo logs：Archived redo logs和Standby redo logs。

通过RFS 进程接收primary 数据库的redo，保存在本地，就是Standby redo logs。 standby redo logs 是standby 数据库特有的文件(如果配置了的话)，就本身的特点比如文件存储特性，配置特性等等都与online redo logs 非常类似，不过它存储的是接收自primary 数据库的redo 数据，而online redo logs中记录的是本机中的操作记录。