oracle高可用性的研究

自己写得出

前言

在信息高速发展的当今社会，数据已成为所有企业的生命线。但是，数据的安全性却面临着越来越大的挑战。包括计算机病毒、网络黑客、软件的缺陷、硬件的损毁、管理人员的误操作等都可能造成数据的缺失,这都将严重威胁企业信息的安全。如何利用一种有效的方法把数据备份到一个安全的地方，而且能够在系统出现故障甚至遭遇灾难之后快速恢复，以使造成的损失降到最低，已成为全世界共同关注的焦点。

作为数据高可用性（High Availability）的最后一道保险——数据备份,自然而然地被广泛关注和实施。本文就oracle数据库的高可用性，对其Data Guard和RAC两种方案进行比较、研究，以便明晰各个方案的特点及适用场合。

1 Data Guard

1.1 Data Guard概述

data guard是ORACLE提供的一种高可用性（High Availability）的数据库方案，它是在主节点与备用节点间通过日志同步来保证数据的同步，可以实现快速切换与灾难性恢复。这是数据库容灾的一种模式，是指在正常运行的生产环境之外异地运行的数据库设备（有自己独立的数据库磁阵），如果生产环境发生数据变动，通过data guard将变动的数据操作从生产环境实时同步过来，保证了生产环境和容灾环境的数据的一致性，如果生产环境数据库瘫痪了，容灾环境就接管过来。data guard存在的目的并不仅仅是为了恢复数据，应该说它的存在是为了确保企业数据的高可用性，数据保护以及灾难恢复(注意这个字眼，灾难恢复)。提供全面的服务包括：创建，维护，管理以及监控standby数据库，确保数据安全，管理员可以通过将一些操作转移到standby数据库执行的方式改善数据库性能。

1.2 Data Guard构成及操作方式

Data Guard是一个集合，同一个Data Guard由一个primary数据库(生产数据库)及一个或多个standby数据库(最多9个)组成。组成Data Guard的数据库通过Oracle Net连接，并且有可能分布于不同地域。只要各库之间可以相互

自己写得出

通信，它们的物理位置并没有什么限制，至于操作系统只要保证能运行oracle即可。可以通过命令行方式管理primary数据库或standby数据库，也可以通过Data Guard broker提供的专用命令行界面(DGMGRL)，或者通过OEM图形化界面管理。

Primary 数据库

前面提到，Data Guard包含一个primary数据库即被大部分应用访问的生产数据库，该库即可以是单实例数据库，也可以是RAC。

Standby 数据库

Standby数据库是primary数据库的复制(事务上一致)。在同一个Data Guard中你可以最多创建9个standby数据库。Standby数据库初始可以通过 primary数据库的备份创建。一旦创建并配置成standby后，Data Guard负责传输primary数据库redo data到standby数据库，standby数据库通过应用接收到的redo data保持与primary数据库的事务一致。Standby数据库同样即可以是单实例数据库，也可以是RAC结构。关于standby数据库，通常分两类：逻辑standby和物理standby。

Data Guard的操作方式

做为oracle环境中一项非常重要的特性，oracle提供了多种方式搭建、操作、管理、维护Data Guard配置：

OEM(Oracle Enterprise Manager)

Orcale EM提供了一个窗口化的管理方式，基本上你只需要点击鼠标就能完全Data Guard的配置、管理、维护等操作，其实质是调用oracle为Data Guard专门提供的一个管理器：Data Guard Broker来实施管理操作。

Sql plus命令行方式

命令行方式的管理，data guard的管理命令并不多。

DGMGRL(Data Guard broker命令行方式)

就是Data Guard Broker，不过是命令行方式的操作。

1.3 Standby 数据库类型

1.3.1 物理standby

物理standby与primary数据库完全一模一样(默认情况下)，Data Guard

自己写得出

通过redo应用维护物理standby数据库。通常在不应用恢复的时候，可以以read-only模式打开，如果数据库指定了快速恢复区的话，也可以被临时性的置为read- write模式。

Redo应用

Redo应用是物理standby的核心。物理standby通过应用归档文件或直接从standby系统中通过oracle恢复机制应用redo文件。恢复操作属于块对块的应用(可理解成块复制，将redo中发生了变化的块复制到standby)。如果正在应用redo，数据库不能被open。

Read-only模式

以read-only模式打开后，你可以在standby数据库执行查询，或者备份等操作(变相减轻primary数据库压力)。此时standby数据库仍然可以继续接收redo数据，不过并不会触发操作，直到数据库恢复redo应用。也就是说read-only模式时不能执行redo应用，redo应用时数据库肯定处于未打开状态。如果需要的话，你可以在两种状态间转换，比如先应用redo,然后read-only，然后切换数据库状态再应用redo。

Read-write模式

如果以read-write模式打开，则 standby数据库将暂停从primary数据库接收redo数据，并且暂时失去灾难保护的功能。当然，以read-write模式打开也并非一无是处，比如你可能需要临时调试一些数据，但是又不方便在正式库操作，那就可以临时将standby数据库置为read-write模式，操作完之后将数据库闪回到操作前的状态(闪回之后，Data Guard会自动同步，不需要重建standby)。

物理standby的特点

灾难恢复及高可用性

物理standby提供了一个健全而且极高效的灾难恢复及高可用性的解决方案。更加易于管理的switchover/failover角色转换及最更短的计划内或计划外停机时间。

数据保护

应用物理standby数据库，Data Guard能够确保即使面对无法预料的灾害也能

自己写得出

够不丢失数据。前面也提到物理standby是基于块对块的复制，因此对象、语句统统无关，primary数据库上有什么，物理standby也会有什么。

分担primary数据库压力

通过将一些备份任务、仅查询的需求转移到物理standby，可以有效节省primary数据库的cpu以及i/o资源。

提升性能

物理standby所使用的redo应用技术使用最底层的恢复机制，这种机制能够绕过sql级代码层，因此效率最高。

1.3.2 逻辑standby

逻辑standby是逻辑上与primary数据库相同，结构可以不一致。逻辑standby通过sql应用与primary数据库保持一致，也正因如此，逻辑standby可以以read-write模式打开，你可以在任何时候访问逻辑standby数据库。同样有利也有弊，逻辑standby对于某些数据类型以及一些ddl,dml会有操作上的限制。

逻辑standby的特点：

除了上述物理standby中提到的类似灾难恢复，高可用性及数据保护等之外，还有下列一些特点：

有效的利用standby的硬件资源

除灾难恢复外，逻辑standby数据库还可用于其它业务需求。比如通过在standby数据库创建额外的索引、物化视图等提高查询性能并满足特定业务需要。又比如创建新的schema(primary数据库并不存在)然后在这些schema中执行ddl或者dml操作等。

分担primary数据库压力

逻辑standby数据库可以在更新表的时候仍然保持打开状态，此时这些表可同时用于只读访问。这使得逻辑standby数据库能够同时用于数据保护和报表操作，从而将主数据库从那些报表和查询任务中解脱出来，节约宝贵的CPU和I/O资源。

1.4 Data Guard的优点

灾难恢复及高可用性

自己写得出

全面的数据保护

有效利用系统资源

在高可用及高性能之间更加灵活的平衡机制

故障自动检查及解决方案

集中的易用的管理模式

自动化的角色转换

RAC

2.1 RAC概述

RAC可以认为是集群，它改变了过去一个实例连接数据库磁阵的处理模式，而是采用多个Oracle实例连接数据库磁阵，各个Oracle实例进行负载均衡。当某个实例down掉时，其他实例像备份一样，依然在工作，这样不影响数据库的使用。对集群来说，所有实例都是运行着的，它不像传统采用双机模式——主机宕机，备机接管，会存在切换时间的问题。

2.2 集群的分类

负载均衡集群（LB）

负载均衡集群为企业提供了更实用的系统。这种集群的核心是把业务的负载流量尽可能平均合理地分摊到集群各个节点。

这种集群系统会计算应用负荷或网络流量负载，非常适合于提供静态内容网站。每个节点都可以处理一部分负荷，并且可以根据节点负载进行动态平衡，以保持负载平衡。对于网络流量，负载均衡算法还可以根据每个节点不同的可用资源或网络的特殊环境来进行优化。

高可用性集群（HA)

高可用性集群侧重于提高系统的可用性，它通过集成硬件和软件的容错性来实现整体服务的高可用。如果群集中的某个节点发生故障，那么将有另外的节点代替他。即使多个节点发生故障，整个系统环境也能保证用户能够访问。

在实际应用的集群系统中，HA和LB这两种基本类型经常会发生混合和交杂。RAC就同时具有HA和LB两种能力。

2.3 RAC集群架构

自己写得出

图2-1

如上图2-1展示了RAC的硬件软件组成，而且从逻辑上显示了RAC集群的层次结构。

图中，RAC集群是由若干物理计算机组成（没个叫做一个节点），这些节点间通过网线连接（心跳线）。每个节点上都运行一个实例（Instance）,这些实例通过一个特殊的软件（Clusterware,集群件）的协助，共同操作一个数据。从外部用户视角来看，他们看到的只是一个数据库。从逻辑上看，RAC集群由存储层、网络层、集群件层、应用层4层组成。

Oracle RAC集群由1到多个服务器组成，每个服务器有一个LAN连接和一个互联连接，必须连接到共享存储器。集群的每个服务器不需要完全相同，但是必须使用同样的操作系统和相同版本的Oracle软件。所有服务器必须支持同一体系结构，如全部为32位或64位。

2.4 Oracle RAC的优缺点

优点

(1)多节点负载均衡;

(2)提供高可用：故障容错和无缝切换功能，将硬件和软件错误造成的影响最小

自己写得出

化;

(3)通过并行执行技术提高事务响应时间----通常用于数据分析系统;

(4)通过横向扩展提高每秒交易数和连接数----通常对于联机事务系统;

(5)节约硬件成本，可以用多个廉价PC服务器代替昂贵的小型机或大型机，同时节约相应维护成本;

(6)可扩展性好，可以方便添加删除节点，扩展硬件资源。

缺点

(1)相对单机，管理更复杂，要求更高;

(2)在系统规划设计较差时性能甚至不如单节点;

(3)可能会增加软件成本(如果使用高配置的pc服务器，Oracle一般按照CPU个数收费)。

3 总结

RAC、Data Guard都从属Oracle高可用性体系，每个工具即可独立应用，也可相互配合。这2个工具虽都能够提供HA功能，但各自的侧重点不同，适用的场景也不尽相同。

就RAC而言，能把多台计算机组织在一起，让多个实例同时对外提供服务是它的主要特点，它的强项在于解决单点故障和负荷均衡，因此RAC方案常见于24*7的核心系统。但RAC方案中数据只有一份，尽管通过RAID等机制可以避免存储故障，但是数据本身是没有冗余的，容易形成单点故障。而Data Guard是通过冗余数据来提供数据保护的。Data Guard通过日志同步机制保证冗余数据和主数据之间的同步，这种同步可以是实时、延时，同步、异步多种形式。Data Guard常用于异地容灾和小企业的高可靠性方案，虽然可以再Standby机器上执行只读查询，从而分散Primary数据库的性能压力，但是Data Guard决不是性能解决方案。

如果从技术角度来比较，Data Guard的原理比RAC要简单得多，Data Guard技术不过是日志恢复技术的一个延伸。Data Guard架构由3部分组成：日志发送、日志接收、日志应用。

从成本而言，Data Guard的实施成本、维护成本都低于RAC,所以Data Guard是许多中小企业钟爱的HA方案.而在银行、证券、电信等要求苛刻的企业，

自己写得出

RAC+Data Guard组合由于能提供最有力的数据保护而倍受青睐。

每种方式的概念、软硬件架构（服务器的部署，网络的部署），优缺点，实际应用。

每种方式的架构其实不止一种，如rac中就有好多种部署方式，每一种的优劣比较。

该文档用于系统开发前的选型和方案确定，不用于文章发表，冠冕唐华的话省略。

本文来源：https://www.bwwdw.com/article/hzuj.html