1.Oracle Data Guard概述<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Oracle在版本7的时候,就支持Standby容灾备份数据库技术,并在Oracle8版本开始支持日志从生产数据库到备用数据库的自动传输。Oracle9i版本把standby技术正式命名为Data Guard。
Data Guard是Oracle的集成化灾难恢复解决方案,该技术可以维护生产数据库一个或多个同步备份,由一个生产数据库和若干备用数据库组成,并形成一个独立的、易于管理的数据保护方案。Data Guard备用数据库可以与生产系统位于相同的数据中心,也可以是在地理位置上分布较远的远程灾难备份中心。
Data Guard的基本原理是,当某次事务处理对生产数据库中的数据作出更改时,Oracle数据库将在一个联机重做日志文件中记录此次更改。在Data Guard中可以配置写日志的这个过程,除了把日志记录到本地的联机日志文件和归档日志文件中,还可以通过网络,把日志信息发送的远程的备用数据库服务器上。这个备用日志文件写入过程可以是实时、同步的,以实现零数据丢失(最大保护模式);也可以是异步的,以减少对网络带宽的压力(最大可用性模式);或者是通过归档日志文件、一个日志文件的批量传输模式,以减少对生产系统的性能影响(最大性能模式)。当备份数据库接收到日志信息后,Data Guard可以自动利用日志信息实现数据的同步。当主数据库打开并处于活动状态时,备用数据库可以执行恢复操作,如果主数据库出现了故障,备用数据库即可以被**并接管生产数据库的工作
Oracle Dataguard数据库灾备原理图
2.物理备用数据库和逻辑备用数据库
当备用数据库接收到从生产数据库传输过来的日志时,根据处理日志方法的不同,可以把Data Guard分为物理备用数据库和逻辑备用数据库两种。物理备用数据库,就是备用数据库处于Mount的状态下,直接利用数据恢复技术,把日志文件中记录的数据变更应用在备用数据库的数据文件上,从而实现与生产数据库的数据同步,在进行数据同步的时候,物理备用数据库是不能打开的、也无法提供数据查询等服务,物理备用数据库也可以通过只读的方式打开,但是,一旦物理备用数据库以只读方式打开后,就只能接收日志,而无法进行数据的同步;逻辑备用数据库,数据库是处于正常的打开状态的,当它接收到新的日志信息后,利用日志挖掘器的功能,把日志中记录的变更信息,转换成具体的SQL语句,并在逻辑备用数据库上执行这些SQL语句,从而实现与生产数据库的数据同步,逻辑备用数据库支持在数据同步的同时,进行数据的查询、报表等操作。Oracle从9i R2开始支持逻辑备用数据库。
3.物理备用数据库的数据保护级别
OracleData Guard 支持多种级别的数据保护模式:最大性能模式,最大可用性模式,最大保护模式。分别对应于“重要信息系统灾难恢复指南”中的5级,5级6级自适应,6级的数据保护级别。其中对应6级的最大保护模式可以实现实时数据实时同步和0数据丢失。另外,Oracle Data Guard 可以设置延时应用时间窗口,从而防范错误操作、黑客攻击等人为错误导致的数据损坏。
要确定适当的数据保护模式,企业需要根据用户对系统响应时间的要求来估量它们对数据保护的业务要求。下表从数据丢失风险的角度概述了各种模式的适用性。
保护模式 |
在出现灾难时数据丢失的风险 |
重做传输机制 |
最大保护 |
零数据丢失 |
LGWR SYNC |
最高可用性 |
零数据丢失 |
LGWR SYNC |
最高性能 |
最小数据丢失 — 通常为几秒 |
LGWR ASYNC 或 ARCH |
最大保护模式
最大保护模式为主数据库提供了最高水平的数据保护,从而确保了一个全面的零数据丢失灾难恢复解决方案。当在最大保护模式下运行时,重做记录由日志写入器 (LGWR) 进程从主数据库同步地传输到备用数据库,并且直到确认事务数据在至少一个备用服务器上的磁盘上可用时,才在主数据库上提交事务。强烈建议,这种模式应至少配置两个备用数据库。当最后参与的备用数据库不可用时,主数据库上的处理将停止。这就确保了当主数据库与其所有备用数据库失去联系时,不会丢失事务。
由于重做传输的同步特性,这种最大保护模式可能潜在地影响主数据库响应时间。可以通过配置一个低延迟网络,并为它分配足够应付高峰事务负载的带宽来将这种影响减到最小。需要这种最大保护模式的企业有股票交易所、货币交易所、金融机构等。
最高可用性模式
最高可用性模式拥有仅次于最高水平的主数据库数据可用性。如同最大保护模式一样,重做数据由 LGWR 从主数据库同步地传输到备用数据库,直到确认事务数据在备用服务器的磁盘上可用时,事务才在主数据库上完成。不过,在这种模式下(与最大保护模式不同),如果最后参与的备用数据库变为不可用 — 例如由于网络连接问题,处理将在主数据库上继续进行。备用数据库与主数据库相比,可能暂时落在后面,但当它再次变为可用时,备用数据库将使用主数据库上累积的归档日志自动同步,而不会丢失数据。
由于同步重做传输,这种保护模式可潜在地影响响应时间和吞吐量。可以通过配置一个低延迟网络,并为它分配足够应付高峰事务负载的带宽来将这种影响减到最小。
最高可用性模式适用于想要确保获得零数据丢失保护,但不想让生产数据库受网络/备用服务器故障影响的企业。如果又一个故障随后影响了生产数据库,然后最初的网络/备用服务器故障得到解决,那么这些企业将接受数据丢失的可能性。
最高性能模式
最高性能模式是默认的保护模式。它与最高可用性模式相比,提供了稍微少一些的主数据库数据保护,但提供了更高的性能。在这种模式下,当主数据库处理事务时,重做数据由 LGWR 进程异步传输到备用数据库上。另外,也可以将主数据库上的归档器进程 (ARCH) 配置为在这种模式下传输重做数据。在任何情况下,均先完成主数据库上的写操作,主数据库的提交操作不等待备用数据库确认接收。如果任意备用目标数据库变为不可用,则处理将在主数据库上继续进行,这对性能只有很小的影响或没有影响。
在主数据库出现故障的情况下,尚未被发送到备用数据库的重做数据会丢失。但是,如果网络有足够的吞吐量来跟上重做流量高峰,并且使用了 LGWR 进程来将重做流量传输到备用服务器,则丢失的事务将非常少或者为零。
当主数据库上的可用性和性能比丢失少量数据的风险更重要时,应该使用最高性能模式。这种模式还适合于 WAN 上的 Data Guard 部署,在 WAN 中,网络的内在延迟可能限制同步重做传输的适用性。
4.<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /><chmetcnv w:st="on" tcsc="0" numbertype="1" negative="False" hasspace="False" sourcevalue="10" unitname="g"><span lang="EN-US">10g</span></chmetcnv> Data Guard存在的不足
建设灾难备份数据库,需要投入基础设施(如机房、场地、人员)、硬件、软件等成本。因此,能否最大程度地充分发挥灾备系统的资源利用率,是很多企业的重要考虑因素。
物理备用数据库所需要的硬件资源不高、数据同步的速度也快,但是,在进行数据同步的同时,数据库是无法打开提供查询访问服务的,而如果用只读方式打开物理备用数据库,则数据同步就无法同时进行,因此,无法满足企业近实时数据查询的需要;而逻辑备用数据库,数据同步的同时、数据库是正常打开的,是可以在数据同步的同时提供对外查询服务的,但是,逻辑备用数据库在使用上存在一定的限制,例如:不支持long、long raw以及用户自定义的数据类型,一般需要为每个表创建关键字或唯一索引等。此外,由于逻辑备用数据库不仅要执行生产数据库上所发生的所有数据变更SQL语句,还需要额外的日志分析工作,因此,硬件资源的配置也相对较高。
有没有办法,把逻辑备用数据库和物理备用数据库的优势结合在一起,既能发挥物理备用数据库同步速度快、耗用资源低,又能够在数据同步的同时,可以进行数据查询,从而充分发挥备用系统的资源利用率呢?这就是Oracle<chmetcnv w:st="on" tcsc="0" numbertype="1" negative="False" hasspace="False" sourcevalue="11" unitname="g">11g</chmetcnv> Active Data Guard的功能。
5.Oracle<chmetcnv w:st="on" tcsc="0" numbertype="1" negative="False" hasspace="False" sourcevalue="11" unitname="g">11g</chmetcnv> Active Data Guard的功能增强
<chmetcnv w:st="on" tcsc="0" numbertype="1" negative="False" hasspace="False" sourcevalue="11" unitname="g"><span lang="EN-US" style="FONT-SIZE: 9pt; COLOR: #333333; LINE-HEIGHT: 180%; FONT-FAMILY: 宋体; mso-font-kerning: 0pt; mso-bidi-font-family: 宋体">11g</span></chmetcnv>以前的Data Guard物理备用数据库,可以以只读的方式打开数据库,但是这时Media Recovery利用日志进行数据同步的过程就停止了,如果物理备用数据库处于恢复的过程中数据库就不能打开查询,也就是说日志应用和只读打开两个状态是互相排斥的,而Oracle<chmetcnv w:st="on" tcsc="0" numbertype="1" negative="False" hasspace="False" sourcevalue="11" unitname="g">11g</chmetcnv> Active Data Guard功能解决了这个矛盾,在利用日志恢复数据的同时可以用只读的方式打开数据库,用户可以在备用数据库上进行查询、报表等操作,这类似逻辑备用数据库的功能,但是,数据同步的效率更高、对硬件的资源要求更低。这样可以更大程度地发挥物理备用数据库的硬件资源的效能(比如对于实时要求比较高的报表服务)。
Oracle<chmetcnv w:st="on" tcsc="0" numbertype="1" negative="False" hasspace="False" sourcevalue="11" unitname="g">11g</chmetcnv> Active Data Guard除了可以运行在只读打开和日志同步应用的场景下,还可以切换到Snapshot Standby状态下运行。运行在Snapshot Standby状态下的物理备用数据库可以用读写的模式打开数据库,但是同时没有破坏它作为物理备用数据库的功能,这个特性可以用来在物理备用数据库上面执行某些测试,等测试完成,把数据库再切换到Physical standby状态下,又可以自动利用日志实现数据同步了。当然在Snapshot Standby以读写方式打开的时候它只能接收生产数据库传过来的日志,但是不能应用这些日志进行数据同步。
例如:把数据库从数据同步和只读打开状态切换到快照备用状态,只需要在备用数据库上执行Alter database convert to snapshot standby;而把数据库从快照备用切换会只读同步状态,只需要执行Alter database convert to physical standby就可以了