UML软件工程组织

Oralce关于灾难防护的几种关键技术综述与分析比对

来源:时代朝阳数据库技术中心 
 一、 Oracle Data Guard

  Oracle9i推出了一种功能强大,更能有效地实施灾难恢复的解决方案Oracle Data Guard

  Oracle Data Guard采用主数据库正常运行,一或多个备用数据库进行备份的方式保护数据库,备用数据库的备份、管理和监视工作都是自动完成的,当主数据库宕机发生时,至少有一个备用数据库马上投入使用,使应用程序的运行不会间断,避免了系统的瘫痪。

(一)、Data Guard的功能简介

1.数据库的切换

  允许DBA将主数据库切换到备用数据库,此备用数据库变为主数据库,响应用户的请求,而原主数据库变为备用数据库。Data Guard的这种特性保证了数据不会丢失,避免数据库恢复期间无法处理用户的请求。

2.通过分布式组态,增强数据库的可用性

  Oracle Data Guard是由主数据库和一到多个备用数据库构成,这些在Data Guard的环境中称为站点,通常各个站点以松散的方式分布在各地,以网络连接,所以,即使遇到地震、火灾、洪水等自然灾害,数据库的数据也会得到很好地保护。Data Guard的结构由下图所示:

3.同步主站点与备用站点的数据

  在Data Guard环境中,将一个站点设置为主站点,用来响应用户的请求,事务对数据库所做的修改,以归档日志的形式由日志传输服务自动从主站点传送到各个备用站点,以实现备用站点与主站点的同步。

4.防止数据库的物理损坏

  由于主站点的物理损坏不可能通过归档日志文件传输到备用站点,所以降低了由物理损坏带给数据库的风险。

(二)、数据库的切换

  将主数据库切换到备用数据库,此备用数据库变为主数据库,而原主数据库变为备用数据库。数据库的切换可以从主数据库角色切换到备用数据库角色,也可从备用数据库角色切换到主数据库角色。

1.主数据库的工作模式:

Guaranteed protection:

规定在修改主数据库时,至少有一个备用数据库有效。假如主备之间的连接中断,通过中断主实例来禁止数据的分歧,保证无数据丢失。这种模式对数据库性能的影响最大。

Instant protection:

规定在修改主数据库时,至少有一个备用数据库有效。与Guaranteed protection模式不同的是当主备之间的连接中断,允许数据分歧,并当恢复连接后,解决数据分歧的现象。无数据丢失,对主数据库的性能有较小的影响。

Rapid protection:

指出主数据库的修改在备用数据库上有效。有数据丢失,最小化对数据库性能的影响。

Delayed protection:

指出主数据库的修改最终在备用数据库上有效。Rapid protection和Delayed protection模式即使在网络连接有效时,也允许主数据库与所有的备用数据库有数据分歧,数据的丢失量等同于主数据库联机重做日志的未归档数。最小化对数据库性能的影响。

四种模式的区别详见下表:

主数据库

保护模式

保护策略

网络连接

主数据库

操作状态

Switchover

Failover

Guaranteed

保护

连接

无数据分歧

无数据丢失

无数据丢失

   

未连接

关闭实例

不可能

无数据丢失

Instant

未保护

连接

无数据分歧

无数据丢失

无数据丢失

   

未连接

Delayed

保护模式

不可能

数据丢失

Rapid

未保护

连接

存在数据分歧

无数据丢失

数据丢失

   

未连接

Delayed

保护模式

不可能

数据丢失

Delayed

未保护

连接

存在数据分歧

无数据丢失

数据丢失

   

未连接

存在数据分歧

不可能

数据丢失

2.备用数据库的工作模式:

Managed recovery mode:

最大化保护数据,主数据库将联机重做日志归档到备用数据库,备用数据库自动应用这些日志进行数据库的恢复。

Read-only mode:

备用数据库不能应用归档日志。在这种模式下,只能对备用数据库进行查询。当备用数据库重新处于mount方式,主数据库继续将日志归档到备用数据库上。

  虽然备用数据库不能同时处于两种模式,但可在两种模式间进行切换。在大多数的Data Guard环境中,备用数据库应处于恢复管理模式。

3.Failover和Switchover的区别

Failover:

  • 将主数据库offline,备用数据库online,这种操作由系统和软件失败引起。
  • 即使在备用数据库上应用重做日志,也可能出现数据丢失的现象,除非备用数据库运行在guaranteed protection模式。
  • 原主数据库重新使用时必须重新启动实例。
  • 其它的备用数据库也需重新启动实例。

Switchover:

  • 故意将主数据库offline,而将另一备用数据库online,它能够切换到备用数据库而不需同步操作。如:可使用Switchover完成系统的平滑升级。
  • 即使在备用数据库上不应用重做日志,也不会造成数据的丢失。
  • 数据库不需重新启动实例。这使主数据库几乎能立即在备用数据库上恢复它的功能,因此可经常进行定期维护而不需中断操作。

  Failover和Switchover的区别为:当Failover发生,备用数据库切换为主数据库之后,它丢失了备用数据库的所有能力,也就是说,不能再返回到备用模式;而Switchover可以,备用数据库可切换为主数据库,也可从主数据库再切换回备用数据库。

4.主数据库与备用数据库的切换

  当主数据库操作在Guaranteed protection和Instant protection两种模式下,可保证数据库在切换的过程中不丢失数据,这意味着主数据库的所有归档日志都必须应用在备用数据库上。假如归档日志没有完全应用,或主数据库工作在Rapid和Delayed protection模式,数据库的切换将导致数据的丢失,数据丢失的总量可由主数据库归档日志路径属性和备用数据库归档日志的应用来决定。

二、ORACLE的高级复制技术

1.基本概念

  复制,顾名思义就是将数据库中的数据拷贝到不同物理地点的数据库中以支持分布式应用,它是整个分布式计算解决方案的一个重要组成部分。

2.高级复制技术的基本结构

  实体化视图在以前的Oracle 版本中叫做“快照”。它被用来复制数据到复制环境中的非主站点。

  实体化视图可以是只读的、可更新的或者是可写的。

(1) 只读实体化视图

  在一个基础结构中,实体化视图可以提供只读的访问表数据,这个表数据来源于一个主体站点或者一个主实体化视图站点。应用程序可以避免访问主体站点和不考虑网络是否可用,它可直接向只读实体化视图请求数据。下图表示只读实体化视图

(2) 可更新的实体化视图

  在一个更高级的结构中,可以创建一个可更新的实体化视图,它允许用户通过在这个可更新的实体化视图上的插入、更新和删除行的操作,来进行同样的插入、更新和删除主表或者主实体化视图上的行。下图表示使用可更新实体化视图

3.实现多主体复制的选择

  同步复制,复制数据在任何时间在任何复制节点均保持一致。如果复制环境中的任何一个节点的复制数据发生了更新操作,这种变化会立刻反映到其他所有的复制节点。这种技术适用于那些对于实时性要求较高的商业应用中。

  异步复制,所有复制节点的数据在一定时间内是不同步的。如果复制环境中的其中的一个节点的复制数据发生了更新操作,这种改变将在不同的事务中被传播和应用到其他所有复制节点。这些不同的事务间可以间隔几秒,几分种,几小时,也可以是几天之后。复制节点之间的数据临时是不同步的,但传播最终将保证所有复制节点间的数据一致。

  过程化复制,成批的处理应用可以在一个单独的事务中改变大量的数据。典型的行层次复制把许多数据改变加载到网络上,为了避免这种问题,一个在复制环境中的批处理应用操作可以使用过程化复制,它只用单一复制存储的过程调用来聚集数据复制品。

三、Oracle9i数据库:应用集群技术

  Oracle9i针对互联网上日益增长的在线应用市场进行了许多关键的改进,它最特别的技术就在于Oracle9i真正应用集群(Oracle9i Real Application )。作为Oracle的新一代群集技术,Oracle9i真正应用集群基于Oracle获得专利的高速缓存熔合体系结构,它能够迅速、有效地在群集的所有计算机上共享那些经常被访问的数据,以提供透明的应用可伸缩性。这一突破性技术,使Oracle9i真正应用集群能够提供超过四个节点的直线性可伸缩性。另一方面,借助Cache Fusion体系结构能够独立处理每个节点的特性,Oracle9i真正应用集群能够为电子商务应用提供令人振奋的可靠性。与其它厂商提供的集群技术相比,Oracle9i真正应用集群是利用独立的计算机专门处理特殊的计算任务,管理数据的特殊“分段”。这种集群技术能够使系统的可伸缩性、性能和可靠性获得最大程度的平衡。因此,在用户集群系统中增加计算机时,既不需要重新分配数据,也不需要重新编写应用程序,Oracle9i真正应用集群能够以透明的方式进行修改,以利用这些新的资源。

1.Real Application Clusters的体系结构

  Real Application Clusters 是由多个节点中能同时访问一个共享数据库的多个组件构成。如图:

Text description of pscon002.gif follows

Real Application Clusters 由下面组件构成:

  • Cluster Manager
  • The Global Cache Service and Global Enqueue Service
  • Cluster Interconnect and Interprocess Communication (Node-to-Node)
  • Disk Subsystems

  在Real Application Clusters环境中,所有的节点可在同一数据库上并发执行事务,Real Application Clusters保证每个节点访问共享数据的一致性和完整性。可以把大的事务分解为多个小事务,在不同的节点执行。它适合DSS、OLTP及混合系统。

2.Oracle9iRealApplicationClusters的特点:

  • “开箱即用”,近线性的透明缩放
  • 与其它程序的良好兼容性,无需重新设计
  • 快速增长的集群,可快速增添节点和磁盘

3.硬件组成

  采用集群数据库技术,最大程度节约硬件投资并保证企业信息存在于一个单一的数据库中。硬件与数据库的数据容量瓶颈曾经困扰企业的信息化建设。企业旧式的解决方法是不断添加成堆成堆的服务器,并让应用分散运行在多个服务器上的多个数据库上。现在的办法有所不同,比如Oracle 9i数据库采用了"集群技术"(Real Application Clusters),它能够让单一数据库同时在多台服务器上运行,而不需要对应用代码或体系结构做出任何修改,此特性极大地改善了系统可靠性:如果数据容量增大,企业可以通过增加小型服务器进行扩充;而在任何一个服务器出现故障时不会对系统造成损害,因为其他服务器可以十分轻松地分担起一部分新增加的负载。此特性还能够缩短数据库访问时间,从而改善应用性能。并使得由多台较便宜的计算机组成的IT数据中心取代昂贵的大型机成为可能,这随着CPU需求的增加能够节省近80%的硬件(在某些情况下,就是数百万美元)。Oracle数据库至今占据了Unix开放系统之下66%以上的份额,它提供了卓越的开放性能,并引领当今数据库技术标准。

高速缓存成亮点:

  Oracle9i Real Application Clusters采用了新的Cache Fusion(高速缓存熔接)技术,Cache Fusion是群集数据库技术的重大突破。在群集中,用户的请求可以被群集数据库的任何高速缓存所响应。当数据正在更新时,Cache Fusion能在各个服务器上的高速缓存之间进行协调,从而保证数据的正常读取和更新。

  如果一个查询请求由一个远程高速缓存所响应,数据块将在从一个节点到另一个节点之间的高速群集中传递,"缓存熔接"过程将自动发生。该过程对于应用是透明的,大大提高了群集的可伸缩性。

  Oracle9i Real Application Clusters几乎和已有的所有网络应用兼容,它支持群集功能,利用它可快速增加网络节点。Oracle9i Real Application Clusters为群集里的所有服务器提供透明的应用可伸缩性,从而解决了一个进程中服务器之间的争端问题。

  Oracle9i设置了一套新的标准,用以防止系统停机导致网络中断,保证系统的高可用性。这些新的功能包括灾难防止、系统错误快速恢复和人为错误的透明恢复等

 

版权所有:UML软件工程组织