Oracle10gRAC应用于数据库的优势分析

Oracle10gRAC应用于数据库的优势分析
Oracle 10g Real Application Cluster
应用于XXX医保数据库
项目的优势分析
目录
第一章
XXX社会医疗保险中心在通过多年的IT系统建设研究与探索，积存了丰富的经验，但关于信息联网形成统一体系、数据汇合整合、挖掘分析、发挥整体协同效能等方面还存在一定差距，强化信息基础建设，建设高可用性、高伸缩性的整体体系是进展的必由之路。

第二章
当前数据库系统存在的问题要紧集中在应变能力差、可伸缩性差，系统运维成本极高、管理复杂，硬件升级成本高昂，不能满足业务扩面的紧迫需求等问题。

如何降低架设与使用信息技术基础架构所需的高昂成本，几乎是所有用户最关心的问题。

然而，要降低IT成本，务必解决过剩的计算容量、昂贵的容量扩展与高额的管理成本三大难题。

受到传统企业计算的限制，用户只能针对高峰容量来构建计算容量，但又无法在平常有效地使用多余的容量，也无法在必要时以较低成本迅速地旧模块单元增加容量，这些因素都是造成 IT成本居高不下的原因。

一种基于网格计算原理的企业网格计算正是用户所需要的，它很好地解决了用户 IT面临的难题。

网格计算是利用网络技术，把分散在不一致地理位置的计算机构成一台虚拟超级计算机。

每一台参与计算的计算机就是其中的一个“节点”（即node），所有的计算机构成了一张节点网就叫“网格”（即Grid，也就是Oracle 10g中g的含义）。

第三章
RAC（Real Application Cluster，真正应用集群）是Oracle数据库支持网格计算环境的核心技术。

它的出现解决了传统数据库应用中面临的一个重要问题：高性能、高可伸缩性与低价格之间的矛盾。

过去，假如用户希望其信息系统具有良好的可靠性、可伸缩性与高性能，就务必选择基于主机的系统，这意味着用户在系统建设之初就务必投入大量资金；假如要节约成本，用户能够选择基于客户机/服务器的计算体系，并在需要时逐步增添新硬件、扩展系统，但假如需要进行应用升级，用户就不得不付出高昂的升级费用，同时这种分布式系统的保护成本也不菲。

使用RAC技术，能够实现多节点共享数据库，并自动并行处理及均分负载，在数据库故障时进行容错与无断点恢复处理。

还显著地提高了大型数据仓库与决策支持系统的性能。

通过与并行查询选件结合，它还提供了节点间的并行性与节点内的
并行性，以得到更高的性能。

使用RAC技术不管是选择基于Intel架构的PC服务器、Unix工作站，还是最近两年颇受关注的刀片服务器；也不管是选择Unix、Windows，还是免费的Linux 操作系统，只要在这些软硬件平台上部署了Oracle 10g的RAC系统，这些分布在各处的系统就能构成集群，实现用户所需的高性能与高可靠性。

且当系统需要进一步扩展时，无需对应用程序进行任何修改。

Real Application Clusters提供了真正的高可用性解决方案，关键的突破是在大多数数据库恢复期间能提供完整的数据库访问。

这使得Real Application Clusters成为电子商务应用所要求的24x7可用性的最佳平台。

Real Application Clusters在高可用性上在三个关键领域胜出：
●提供了数据库恢复期间的数据块访问
●透明的失效转移对最终用户屏蔽了系统失效
●N-1节点失效的容错能力
只要有一个数据库节点幸存，Real Application Clusters就能够提供完全的数据库访问与相对不间断的操作。

Real Application Clusters实现了真正意义上的一个单系统访问数据库，它提供了从任何节点到所有磁盘设备与远程高速缓存进行无缝数据访问的能力。

此单系统映像延伸到所有数据库管理操作。

安装、配置、备份、升级与监控等操作只需进行一次，然后会自动公布到集群中所有节点上去。

各类Oracle工具（如Oracle Universal Installer、Database Configuration Assistant与Recovery Manager）将发现集群数据块中所有不一致的节点并以它们为目标分配给想得到的任务。

通过为特定的管理操作选择多个目标节点，管理任务在数据库集群中多个节点上执行。

这为电子商务管理其环境带来了极大的可伸缩性上的经济实惠。

比如，向数据库集群添加一个节点只会增加最小的管理任务。

这样，Real Application Clusters支持在线电子商务应用与决策支持之类的应用，同时为数据访问与管理提供了单一的虚拟高性能服务器。

基于RAC的电子商务应用的用户或者者中间层应用服务器客户，能够通过虚拟数据库服务名连接到数据库上。

Oracle在集群中多个节点之间自动平衡用户负载。

不一致节点上的Real Application Clusters数据库实例预订所有数据库服务或者者部分子集数据库服务。

这使得DBA高度灵活地选定，连接到特定数据库服务的特定应用程序客户是否能够连接到某些或者者全部的数据库节点。

尽管每一个节点有一个不一致的物理IP地址时，应用客户仍能够在一个逻辑数据库服务名的水平上进行连接。

因此客户端关于不有关的情况如多服务器的多个地址能够毫不关心。

随着业务的增长，电子商务能够从容地增加处理能力。

Cache Fusion体系结构直接地利用新节点的CPU与内存资源。

DBA无需用手工对数据重新分区。

这个优点是这种体系结构的副产品，由于有透明度的数据存取是Cache Fusion的一项基本功能。

Cache Fusion体系机构自动习惯快速变化的电子商务需求及随之而来的工作负荷的改变。

DBA也不必由于工作负荷变化而对数据进行手工的重新分区。

Real Application Clusters通过动态地重新分配数据库资源，从而在节点之间用最小化的磁盘I/O与低的延迟通信来优化利用集群系统资源。

这使得Real Application Clusters能够从容实现增加的应用吞吐量与优化的响应时间。

第五章
在Cluster (集群)多机系统平台上，常用的高可用性技术有两种：双机热备份与并行服务器。

这两种方式使用的机制不一致，实现的效果也不一致。

Real Application Cluster实现的是并行服务器方式。

双机热备份方式
如上图所示，在双机热备份方式下，数据库系统平常只能在一台服务器(比如服务器A)上运行，另一台服务器无法直接访问数据库，自然也无法进行负载分担。

当服务器A由于故障失效时，由相应的操作系统软件操纵，将服务器A管理的存储设备(如硬盘)转交给服务器B操纵，同时在服务器B上启动另一个数据库进程，管理数据库。

这种切换并启动新的数据库核心的过程通常需要几十秒到几分钟。

这种方式的要紧缺点在于：
●由于需要重新启动数据库核心进程，无法保证数据库系统连续不间断地
运行
●在系统切换的过程中，客户端与服务器之间的数据库连接会中断，需要
重新进行数据库的连接与登录工作
●由于数据库系统只能在一台服务器上运行，另一台服务器无法分担系统
的负载，实际上造成了客户投资的浪费。

在有些系统中，为熟悉决双机负载
分担的问题，将应用系统人为分割为两个数据库系统，分别在两台服务器上
运行。

这种方式在一定程度上解决了负载分担的问题，但给系统管理、统计
分析等业务处理带来了很多额外的复杂性
并行服务器(Real Application Cluster)方式
在并行服务器方式下，两台(或者多台)服务器上各自运行一个数据库核心进程，但共同管理、操作一个数据库。

客户端不管连接到哪个服务器都能够在数据库中进行操作。

当服务器A由于故障失效时，数据库系统本身并未停止工作，连接在服务器B上的客户端还能够继续进行正常工作。

同时，服务器B上也不需要再启动新的数据库服务器进程，因此也没有“切换时间”。

关于一些特殊应用中严格要求前端应用不能中断的情况，Oracle并行服务器还提供了一种“预连接(pre-connect)”方式，以这种方式连接的客户端当服务器端发生故障时，客户端与数据库服务器的连接不可能中断，会被Oracle并行服务器软件自动转接到还在正常工作的其它服务器上，不需要重新输入用户名及口令。

与双机热备份方式相比，Oracle10g Real Application Cluster并行服务器方式有下列优点：
●各服务器共享一个数据库，在正常运行时能够进行负载分担，无需考虑
应用数据的人为分割。

●并行服务器方式对应用完全透明，在应用程序设计与开发的过程中也不
需要进行特殊编程，简化了开发的复杂程度，同时今后系统扩展也无需修改
应用程序。

不需要重新启动数据库核心进程，缩短了故障造成的停机时间。

第六章
假如使用 RAC，用户不必花巨资购买大型主机来满足高可靠性要求，也不必担心单点系统故障对用户造成难以估计的缺失。

当系统需要进一步扩展时，可按需增加节点，无需对应用程序进行任何修改，也无需更换新的服务器，更不必考虑服务器系统平台是什么。

企业网格计算的实现，解决了用户 IT面临的三大难题，降低了用户 IT成本，这是企业网格计算带来的显著优点，也是未来信息技术进展的方向。

第七章
最基本的不一致是，Oracle Real Application Clusters 10g中所有服务器都能够直接访问数据库中的所有数据，其他的数据库在开放系统中都做不到这点，正是由于这个原因，您能够非常方便地根据需求随时增加服务器来扩充您的系统，无需重新分布数据与应用。

Real Application Clusters象一个单一的系统一样工作，任何节点的故障都不可能影响其他节点对数据的访问。

因此说增加服务器就增加了系统的可靠性。

另外一点，对用户来说RAC是一个数据库系统，对它的保护管理如同单机一样简单方便。

您认为Oracle RAC的典型硬件配置是什么样的?
首先我们明白 RAC选件支持所有的Oracle数据库支持的平台，如: Windows, Linux, Solaris, HP-UX等等。

因此不管您选择什么样的系统，RAC都能够非常好的运行。

假如是系统选型，那要取决于您的应用需求。

我们能够看到Windows与Linux 平台都是常用的基于Intel架构的平台，RAC 在这些平台都有很好的表现，这意味
着您能够以低成本得到更高的可用性、可靠性与伸缩性。

同时，RAC可以在任何价位上获得良好的性能，您能够在HP SuperDomes、Sun boxes或者Linux/Windows Intel服务器上非常方便地配置RAC。

与IBM DB2都有active-active的故障切换方式，为什么我要使用Oracle Real Application Cluster 10g ?
其他的数据库系统都无法真正的支持 active-active方式的集群系统，即集群的两个节点能够支持同样的应用。

实际上，他们只能支持双向的active-passive 架构，即节点 A运行应用A，同时节点B运行应用B，每个节点作为另一个节点的备份节点。

但是同样的应用无法同时运行在两个不一致的节点。

在Oracle Real Application Cluster 10g中，同样的应用能够运行在两个或者更多的节点，每一个节点都可作为所有其它节点的备份机。

当出现单点故障时，整个Real Application Clusters数据库系统的效率只会有很小的降低。

假如您的应用系统正运行于Oracle上，他们当然能够支持您的业务需求。

但是集群的数据库能够让您管理更少的数据库，意味着更少的管理成本。

同时假如您把数据集中到Oracle Real Application Cluster 10g上，您能够提高整个系统的可用性，达到99.99%甚至更高。

当您在集群环境下运行您的应用，假如不使用Oracle Real Application Clusters 10g的话，您的应用是运行于单例程状态下。

尽管您的服务器是集群的一部分，但实际上相当于只运行在一台单机上。

在硬件集群环境下，如HP ServiceGuard、 Sun Cluster与 Microsoft Cluster Services,您能够在集群的任何一个节点重新启动 Oracle数据库 (由于硬盘能够共享).这就是我们所说的“cold failover”。

”Cold failover”切换速度依靠于有关硬件资源的切换速度，这可能需要5到 25分钟的时间恢复。

假如使用Oracle Real Application Clusters 10g，在服务器发生故障时，其他存活的服务器能够自动快速的恢复故障服务器的例程。

Oracle Real Application Clusters 10g能够提供业界最快的系统恢复，在60秒内能够对系统故障进行恢复，这至少比硬件的“cold failover”方案快5倍。

使用Data Guard来保护您的数据是一个正确的选择 - Data Guard能够在各类故障情况(不管是数据坏块还是人为失误)下保护您的数据，Data Guard也确实提供故障切换的功能，但是切换时间可能会需要10分钟，RAC可以提供低于60秒的切换。

同时RAC还能够提供无限的伸缩性，Data Guard只能提供有限的伸缩性。

RAC 与Data Guard提供100%技术来最大程度地保护您的数据库应用。

使用SMP UNIX服务器的原因是他们在过去能够为您的业务系统提供高可用性与伸缩性。

在今天对成本非常敏感的环境下，我们需要一种低成本的能够提供高可用性与高质量的系统。

通过把您的应用系统迁移到Linux环境下的Oracle Real Application Clusters 10g，您能够得到比SMP服务器更好的可用性，同时能够方便地扩充您的系统，最关键的是总体拥有成本能够操纵的很低。

使用小型 Intel服务器构建集群成本远远低于大型的SMP服务器，同时能够拥有无限的伸缩性。