它有无数个名字,有人叫它dg,有人叫它数据卫士,有人叫它data guard,在oracle的各项特性中它有着举足轻理的地位,它就是(掌声)......................Oracle Data Guard。而对于我而言,我一定要亲切的叫它:DG(注:主要是因为打着方便)。
不少未实际接触过dg的初学者可能会下意识以为dg是一个备份恢复的工具。我要说的是,这种形容不完全错,dg拥有备份的功能,某些情况下它甚至可以与primary数据库完全一模一样,但是它存在的目的并不仅仅是为了恢复数据,应该说它的存在是为了 确保企业数据的高可用性,数据保护以及灾难恢复 ( 注意这个字眼,灾难恢复) 。dg提供全面的服务包括:创建,维护,管理以及监控standby数据库 , 确保数据安全 , 管理员可以通过将一些操作转移到standby数据库执行的方式改善数据库性能 。后面这一长串大家可以把它们理解成形容词,千万不要被其花哨的修饰所迷惑,要抓住重点,要拥有透明现象看本质的能力,如果没有那就要努力学习去拥有,下面我来举一个例子,比如我们夸人会说它聪明勇敢善良等等,这些就属于形容词,不重要,重点在于我们究竟想形容这个人是好人还是坏人。然后再回来看看oracle对dg功能上的形容,数据保护和灾难恢复应该都可以归结为高可用性,那么我们可以清晰的定位dg的用途了,就是构建高可用的企业数据库应用环境。
一、 Data Guard 配置(Data Guard Configurations)
Data Guard 是一个集合,由一个primary数据库(生产数据库)及一个或多个standby数据库(最多9个)组成。组成Data Guard的数据库通过Oracle Net连接,并且有可能分布于不同地域。只要各库之间可以相互通信,它们的物理位置并没有什么限制,至于操作系统就更无所谓了(某些情况下),只要支持oracle就行了。
你即可以通过命令行方式管理primary数据库或standby数据库,也可以通过Data Guard broker提供的专用命令行界面(DGMGRL),或者通过OEM图形化界面管理。
1. Primary 数据库
前面提到,Data Guard包含一个primary数据库即被大部分应用访问的生产数据库,该库即可以是单实例数据库,也可以是RAC。
2. Standby 数据库
Standby 数据库是primary数据库的复制(事务上一致)。在同一个Data Guard中你可以最多创建9个standby数据库。一旦创建完成,Data Guard通过应用primary数据库的redo自动维护每一个standby数据库。Standby数据库同样即可以是单实例数据库,也可以是RAC结构。关于standby数据库,通常分两类:逻辑standby和物理standby,如何区分,两类各有什么特点,如何搭建,这方面内容就是后面的章节主要介绍的,在这里呢三思先简单白话一下:
- 逻辑standby
就像你请人帮你素描画像,基本器官是都会有的,这点你放心,但是各器官位置啦大小啦肤色啦就不一定跟你本人一致了。
- 物理standby
就像拿相机拍照,你长什么样出来的照片就是什么样,眼睛绝对在鼻子上头。或者说就像你去照镜子,里外都是你,哇哈哈。具体到数据库就是不仅文件的物理结构相同,甚至连块在磁盘上的存储位置都是一模一样的(默认情况下)。
为什么会这样呢?这事就得从同步的机制说起了。逻辑standby是通过接收primary数据库的redo log并转换成sql语句,然后在standby数据库上执行SQL语句(SQL Apply)实现同步,物理standby是通过接收并应用primary数据库的redo log以介质恢复的方式(Redo Apply)实现同步。
另外,不知道大家是否注意到形容词上的细节:对于相机拍照而言,有种傻瓜相机功能强大而操作简便,而对于素描,即使是最简单的画法,也需要相当多的练习才能掌握。这个细节是不是也说明逻辑standby相比物理standby需要操作者拥有更多的操作技能呢?
二、 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 保护模式(Data Guard Protection Modes)
对于Data Guard而言,其生存逻辑非常简单,好好活,做有意义的事,做黑多黑多有意义的事:)
由于它提供了三种数据保护的模式,我们又亲切的叫它:有三模:
- 最大保护(Maximum protection):
这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的,它要求所有的事务在提交前其redo不仅被写入到本地的online redo log,还要同时提交到standby数据库的standby redo log,并确认redo数据至少在一个standby数据库可用(如果有多个的话),然后才会在primary数据库上提交。如果出现了什么故障导致standby数据库不可用的话,primary数据库会被shutdown。
- 最高性能(Maximum performance):
这种模式提供在不影响primary数据库性能前提下最高级别的数据保护策略。事务可以随时提交,当前primary数据库的redo数据也需要至少写入一个standby数据库,不过这种写入可以是不同步的。
如果网络条件理想的话,这种模式能够提供类似最高可用性的数据保护而仅对primary数据库有轻微的性能影响。
- 最高可用性(Maximum availability):
这种模式提供在不影响primary数据库可用前提下最高级别的数据保护策略。其实现方式与最大保护模式类似,也是要求所有事务在提交前必须保障redo数据至少在一个standby数据库可用,不过与之不同的是,如果出现故障导入无法同时写入standby数据库redo log,primary数据库并不会shutdown,而是自动转为最高性能模式,等standby数据库恢复正常之后,它又会再自动转换成最高可用性模式。
最大保护及最高可用性需要至少一个standby数据库redo数据被同步写入。三种模式都需要指定LOG_ARCHIVE_DEST_n初始化参数。LOG_ARCHIVE_DEST_n很重要,你看着很眼熟是吧,我保证,如果你完完整整学完dataguard,你会对它更熟。
四、 Data Guard 优点总结
|