Oracle RAC & Data Guard搭建高可用数据库系统方案

[align=center]Oracle RAC & Data Guard[/b]搭建高可用数据库系统方案[/b][/align]
[align=center] [/b]作者： [/b]铁 [/b]钉[/b][/align]
Q Q[/b]： 5979404[/b]
MSN[/b]： nail.cn@msn.com[/b]
Mail: nail.cn@msn.com[/b]
Blog: http://nails.blog.51cto.com[/b]
一、高可用系统平台[/b]
Oracle Real Application Clusters (RAC)可以支持24 x 7 有效的数据库应用系统，可以由低成本的服务器构成的高可用性系统，自由的部署应用，而无需修改应用程序。

([/b]一) RAC[/b]关键特性[/b]
l 高可用性
Oracle Real Application Clusters 提供一个高性能低成本的应用平台，支持所有类型的应用系统，无论是事务处理型应用还是分析型应用。所有应用共享同样的服务器和存储资源。出现任何的服务器或磁盘故障，系统会自动重新接管发生故障的功能。这些对前端用户的完全透明的。同样，如果您需要增加服务器或改变其他组件的配置也不会影响到应用系统。
l 高性能
Oracle Real Application Clusters保持着TPC-C的记录，达到每分钟 118万个事务的处理能力，和仅仅 $5.52 每tpmC的成本。在3,000 GB的 TPC-H数据仓库Benchmark 测试中, Oracle RAC同样保持性价比的领先地位，保证我们的用户能够达到更好更快的 ROI。这仅仅是Oracle 保持的多项Benchmark 记录中的最 近的一些指标。
l 按需扩充
在现有的系统可能是基于当前的工作负载而构建的，当应用规模需要扩充时(支持更多的数据、用户或应用)，就需要扩展系统以保证系统的性能。当您的应用是构建于大型的SMP主机时，您可能需要购买另一 台昂贵的主机，但可能只能使用到其处理能力的很小一部分。但是如果您使用Oracle RAC的话，您可以通过增加一台或多台低成本的服务器来扩充您的应用系统的处理能力，满足应用需 求。

[/b]
([/b]二) RAC[/b]逻辑结构[/b]
从逻辑结构上看，每一个参加集群的节点有一个独立的instance，这些instance访问同一个数据库。节点之间通过集群软件的通讯层（communication layer）来进行通讯。同时为了减少I/O的消耗，存在了一个全局缓存服务，因此每一个数据库的instance，都保留了一份相同的数据库cache。
l RAC中逻辑结构的特点是：
a) 每一个节点的instance都有自己的SGA ，
b) 每一个节点的instance都有自己的background process，
c) 每一个节点的instance都有自己的redo logs ，
d) 每一个节点的instance都有自己的undo表空间 ，
e) 所有节点都共享一份datafiles和controlfiles。
l 提出了一个缓存融合的技术(Cache fusion)，目的有两个：
a) 保证缓存的一致性，
b) 减少共享磁盘I/O的消耗。
l 因此在RAC环境中多个节点保留了同一份的DB Cache，缓存融合（Cache fusion）工作原理：
a) 其中一个节点会从共享数据库中读取一个block到db cache中，
b) 这个节点会在所有的节点进行交叉db block copy ，
c) 当任何一个节点缓存被修改的时候，就会在节点之间进行缓存修改 ，
d) 为了达到存储的一致最终修改的结果也会写到磁盘上ClusterWare组件 。
l 有四种Service：
a) 　　Crsd - 集群资源服务
b) 　　Cssd - 集群同步服务
c) 　　Evmd - 事件管理服务
d) 　　oprocd - 节点检测监控
l 　　有三类Resource：
a) 　　VIP - 虚拟IP地址(Virtual IP)
b) 　　OCR - Oracle Cluster Registry(集群注册文件),记录每个节点的相关信息
c) 　　Voting Disk - Establishes quorum (表决磁盘),仲裁机制用于仲裁多个节点向共享节 点同时写的行为，这样做是为了避免发生冲突。
l 　　RAC的组件提供过了额外的进程，用来维护数据库：
a) 　　LMS - Gobal Cache Service Process 全局缓存服务进程
b) 　　LMD - Global Enqueue Service Daemon 全局查询服务守护进程
c) 　　LMON - Global Enqueue Service Monitor全局查询服务监视进程
d) 　　LCK0 - Instance Enqueue Process 实例查询进程

（三）RAC [/b]的物理结构[/b]
组成RAC的服务器称为节点，每台节点服务器至少需要2张网卡。 物理连接分三大系统，共享磁盘存储系统、专用网络系统、公用网络系统。
l 共享磁盘存储(Storage Share)
Oracle RAC 依赖于一个共享磁盘体系结构。 数据库文件、联机重做日志和数据库的控制文件必须都能为集群中的每个节点所访问。共享磁盘还存储 Oracle Cluster Registry 和 Voting Disk。 配置共享存储有多种方法，包括直接连接磁盘（通常是使用铜缆或光纤的 SCSI）、存储区域网 (SAN) 和网络连接存储 (NAS)。
l 专用网络(Private Network)
每个集群节点通过专用高速网络连接到所有其他节点，这种专用高速网络也称为集群互联或高速互联 (HSI)或心跳检查(Heart Check)。 Oracle 的 Cache Fusion 技术使用这种网络将每个主机的物理内存 (RAM) 有效地组合成一个高速缓存。 Oracle Cache Fusion 通过在专用网络上传输某个 Oracle 实例高速缓存中存储的数据允许其他任何实例访问这些数据。 它还通过在集群节点中传输锁定和其他同步信息保持数据完整性和高速缓存一致性。
l 公共网络(Public Network)
为维持高可用性，为每个集群节点分配了一个虚拟 IP 地址 (VIP)。 如果主机发生故障，则可以将故障节点的 IP 地址重新分配给一个可用节点，从而允许应用程序通过相同的 IP 地址继续访问数据库。
[/b]
[/b]
[/b]
[/b]
[/b]
（四）Oracle RAC[/b]系统结构图[/b]
[/b]

二、高可用、高安全系统平台[/b]
（一）RAC + Data Guard[/b]数据卫士[/b]
现在大多企业都已采用Oracle RAC，且已有数据备份系统，那为什么还要采用Data Guard呢？因为Data Guard 的数据保护可以实现主库（Primary Database）和备库（Standby Database）数据实时同步，并且在Oracle RAC完全不可用的严重灾难时，快速的将备库切换到对外服务模式，使业务得以快速恢复，保障业务数据系统的高可用及高安全。
Data Guard的最主要的功能是冗灾。根据冗灾技术，可以分为物理Standby和逻辑Standby两种；根据保护级别的不同可分为：最大保护、最大可用、最大性能。
（二） [/b]冗灾技术模式[/b]
Data Guard可以分为物理Standby和逻辑Standby两种。二者的最大差别在于，物理Standby应用的是主库的归档日志，而逻辑Standby应用的是主库的归档日志中提取的SQL语句。由于两者这一区别，决定了物理Standby无论从逻辑结构和物理结构都是和主库保持一致，而逻辑Standby则只需保证逻辑结构一致，且逻辑Standby在应用SQL语句的时候，数据库可以处于打开的状态，在企业的核心数据库，首选物理Standby技术。

([/b]三) [/b]三种数据保护模式：[/b]
l 最大保护(Maximum protection)
这种模式主库(Primary Database)备库(Standby Database)之间数据是实时同步的。即主库提交的同时，备库会做相应的恢复，最大程度的保证了数据完整性，不允许数据的丢失。如果主、备库之间网络，或者备库出现问题会直接影响主库操作，导致主库当机，以保证主、备库数据的绝对相同。
l 最高可用性(Maximum availability)
这种模式和"最大保护"基本上差不多。正常情况下，主、备库之间是同步的。 当网络或者备库出现问题时，不会影响到主库的当机，主库会自动转换库"最大性能"模式，等待备库可用时，将归档传输到备库做恢复。可以把这种模式理解为"最大保护"和"最大性能"两种模式的中间体。
l 最高性能(Maximum performance)：
这种模式保证主库性能最大化，主备库之间数据是异步传输的。即主库日志归档以后才会传输到备用库，在备库上使用归档日志文件做恢复操作。如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护而仅对主数据库有轻微的性能影响。

([/b]四) Oracle RAC and Data Guard [/b]结构图[/b]
[/b]

作者： [/b]铁 [/b]钉[/b]
QQ[/b]： 5979404[/b]
MSN[/b]：nail.cn@msn.com[/b]
Mail[/b]: nail.cn@msn.com
Blog: http://nails.blog.51cto.com本文出自 “铁钉” 博客，请务必保留此出处http://nails.blog.51cto.com/640492/362856