Oracle-RAC数据库学习总结

一． 编写目的

    为响应部门领导号召，本着谦虚严谨的工作原则和积累知识经验，使知识与经验在部门中可有效被借鉴的精神，借助此次Oracke-RAC实施部署安装的机会，进行学习与思考，并将在此过程中需要总结的知识与经验编入本文档，以供领导、同事审阅。

二． 数据库介绍

1. 数据库定义

数据库是依照某种数据模型组织起来并存放在二级存储器中的数据集合。这种数据集合具有如下特点：数据尽可能无冗余，以最优方式为某个特定组织的多种应用提供数据存储服务，其数据结构独立于使用它的应用程序，对数据的增、删、改、查进行统一管理和控制。从发展的历史看，数据库是数据管理的高级阶段，它是由文件管理系统发展起来的。

2. 数据库与文件系统的区别

1)  数据的结构化

对数据进行结构化组织，是控制数据、使用数据的根本方法，它本质上是对数据进行描述，使数据被赋予意义，通过对数据进行结构化组织，使用数据的对象才可以有所指的对数据进行有序、有意义的控制。

文件系统对于数据本身不进行结构化解释，所有存放在文件系统上的文件最终反映到硬盘上的结构都是简单的二进制格式，这些二进制数据集合（文件）的结构最终由使用它的应用程序进行解释。

数据库对于数据的本身进行了结构化的定义与组织，只要是通过数据库存放的数据，都会存在这一过程，数据库面向应用程序提供了统一的结构化解释；所以对于应用程序，在二进制数据集合这一层面来说，应用程序将不用再对二进制数据集合进行结构化解释。

数据的结构化定义实际上是赋予数据以“道”，而数据的结构解释是数据的“名”，无道无名则数据不可用。

2)  数据冗余

数据冗余指的是，某一数据在特定区域存在多份的情况，冗余可能是行为导致的有意义结果，也可能是行为导致的无必要的结果。这里说明一下，文件系统在实际运用情况中会存在无必要的数据冗余。

例如：一个计算工资的excel文件中记载了“张三，23岁”的数据，而另一个管理员工的excel文件中，同样也记载了“张三，23岁”的这个数据，这是它们就形成了一种冗余，这里只是罗列了一个量级较小的例子，实际情况中量级会更大，数据的冗余将导致存储的低利用率。

而数据库的数据组织方法，可以提供降低无必要的数据冗余的简单有效方法，从而完成存储的高利用率。例如：工资表中只有“张三”这个数据作为外KEY，而无“23岁”的这个数据，“23岁”将在员工表中予以存放，这是一个较为简单的数据库消除数据冗余的例子。

3)  数据一致性

数据冗余的存在必然带来数据一致性问题，无论是有意义的冗余还是无意义的冗余都会存在这个问题。在有意义的数据冗余中，通常利用哈希算法来计算冗余项的MD5值，通过冗余项之间的MD5值的比对，来解决一致性问题；在无意义的数据冗余中，通常数据的一致性问题会被忽略和忘记，从而产生严重的后果。

例如：文件系统中，还是工资与员工两张excel文件，随着时间的变化，张三变成了24岁，那么管理员工信息的管理员就会将张三的年龄改成24岁，但由于冗余项的存在，工资表中的“张三，23岁”可能会被忘记更改，这将导致对工资表的一系列应用操作都将产生误差，从而影响到应用功能的准确性。

而利用数据库中的“范式”可以解决这一层面上的数据一致性的问题，所谓关系型数据库，就是将数据与数据之间建立关系，使其上的数据形成一个个的数据指针链。例如：将工资表中的张三设置为外KEY，那么无论员工表中张三的年龄如何变化，应用程序通过工资表调用张三这一条数据时，都会通过外KEY去查询员工表信息，这样将获取最准确实时的数据，从而解决了数据一致性问题。

4)  数据共享性

数据的共享性是指，数据的结构是否能被广泛的解释与认知，因为文件系统不负责数据的结构化解释，所以就需要应用程序来解释，而解释的方法通常是特殊的，仅为该应用程序知道的，从而导致其他应用程序无法读取控制这个文件。

例如：一个doc文件，它的数据结构与结构解释都是word这个应用程序来定义的，如果拿记事本打开doc文件的话，就会呈现出乱码，这是因为记事本不了解doc的数据结构，无法解释它。而WPS这种应用程序之所以能打开doc文件，是因为它对doc文件的结构进行了学习，否则它也无法读取doc文件。文件的结构特殊化导致其数据共享性较差。

而数据库提供了数据结构与结构解释的统一、通用的标准与语义，只要是按照数据库提供的结构进行存放的数据，利用通用的语义就可以解释数据。数据库将数据的结构、解释独立化，使其结构、解释与应用程序无关，所以在这一层面上来说，数据库对于数据的共享性更具优势。

三． Oracle-RAC介绍

1. RAC简介

1)  定义

RAC全称为Real Application Clusters, 是Oracle9i新版数据库中采用的一项新技术，也是Oracle数据库支持网格计算环境的核心技术。它的出现解决了传统数据库应用中面临的一个重要问题：高性能、高可伸缩性与低价格之间的矛盾。它一般有两台或者两台以上同构计算机及共享存储设备构成，可提供强大的数据库处理能力，现在是Oracle 10g Grid应用的重要组成部分。Oracle RAC主要支持Oracle9i、10g、11g版本，可以支持7x24有效的数据库应用系统，在低成本服务器上构建高可用性数据库系统，并且自由部署应用，无需修改代码。在Oracle RAC环境下，Oracle集成提供了集群软件和存储管理软件，为用户降低了应用成本。当应用规模需要扩充时，用户可以按需扩展系统，以保证系统的性能。

2)  特点

A.   负载均衡能力

B.   高可用性/无缝切换

C.   具有

D.   具有可扩展的并发能力

E.   Cheep & Common，支持便宜和标准化的PC

F.   易扩展性

3)  相关集群功能实现机制

1. Load Balance实现机制（下简称LB）

1）  面向连接的LB机制

Oracle RAC的LB机制分为两种，一种是客户端模式，另一种是服务端模式，这两种模式在8i与9i分别推出，现在最新版本用的是两种模式来共同实现LB功能。

A． Client-Side客户端模式（8i）

客户端模式实现LB功能的机制很简单，在每个需要连接数据库的客户端都存在一个配置文件tnsnames.ora，在该配置文件中将LB选项打开，并配置一个以上的数据库服务节点的地址；当客户端发起连接时，客户端会对该文件中的服务节点的地址进行随机判定，根据随机判定结果进行连接。

这种模式的优缺点都很明显，优点是简单，不需要进行过的的设置就可以实现LB功能。缺点是客户端在进行连接时并不知道服务端的真实集群负载情况，在大多数情况下都不能有效的实现LB功能，属于一种理想化的LB机制。

B． Server-Side服务端模式（9i）

由于客户端的LB模式存在较大缺陷，所以Oracle在9i中推出了服务端模式的LB实现机制，它的实现依赖于服务端Listener收集集群各节点的负载信息。 在数据库运行过程中，后台进程会收集系统的负载信息，然后登记到Listener中。 最少1分钟，最多10分钟后台进程就要做一个信息更新，并且如果节点的负载越高，更新频率就越高，以保证Listener能掌握每个节点准确的负载情况。有了后台进程的自动注册机制后，集群的每个节点的Listener都掌握所有节点的负载情况，当收到客户端连接请求时，就会把连接转给负载最小的节点，这个节点有可能是自己也有可能是其他节点，也就是Listener 会转发用户的请求。

这种模式的优点相对于客户端模式来讲非常明显，它真正掌握集群的负载情况，并且通过请求转发的方法实现负载均衡。

疑问1：请求转发的内部机制是如何实现的？

2）  面向业务（Service）的LB机制

在论述面向业务的LB机制之前，先说明一下缓存融合（Cache Fusion）的作用，缓存融合是Oracle RAC集群数据库实现数据同步功能的一种机制，它保证了数据一致性。

例如：一个ERP 应用包括生产，销售，供应链管理多个模块。假设这个数据库采用了2个节点的RAC，在没有进行“分散数据”之前，两个用户都使用销售模块，那么这两个用户就可能被分配到两个节点上，在操作过程中，销售数据就要在Cache Fusion的作用下，不断在两个节点间传递。如果又来了另外两个生产模块的用户，在两个用户被分配到两个节点上，在操作过程中，生产部分又要在Cache Fusion的协助下在两个实例间同步。如下图所示：

可见，如果仅有面向连接的负载均衡一种机制，表面上看起来用户是被分散到了不同的节点上，似乎负载被分散了。 但是这种分散是没有结合每个用户的业务需求下进行的，是一种纯技术手段。这种分散反而可能加重了系统间的负担。

实例间通过Cache Fusion机制进行数据同步，所以RAC的性能在很大程度上受限于Cache Fusion的性能。 因此，要提高RAC的性能，可以从两方面入手：

A.  提高Cache Fusion的能力，这个可以使用更好的互联设备，比如G级的private network，或者使用Infiniband等高性能网络。

B.  可以尽量减少Cache Fusion的流量，减少实例间的互相依赖。而Service就是后一种思路基础上发展出来的。

Service的思路是这样：假如把销售模块的用户都分配到节点1上，生产模块的用户都分配到节点2上，再假设这两个模块之间的数据交叉不多。 这时销售模块的数据都集中在节点1上，生产模块的数据都集中在节点2上， Cache Fusion的工作量就会急剧较少，就能从根本上解决了性能问题。如下图所示：

这个思想就是借助Service 分散负载的基本思想。通过把应用按照功能模块进行划分成Service，进而把每个Service固定在某个RAC 节点上，从而从根本上体统系统的性能。 这种分散负载的方法不是仅靠DBA进行配置就能完成的，需要DBA 和开发人员合作，在了解业务数据特点之后才可能看到效果。

在RAC环境下，Service 并不是必须的，但是如果能借助Service 对应的划分，对整个系统性能的提升是有很大好处的。

2. High Availability实现机制（下简称HA）

Oracle RAC高可用性的技术基础是Failover，是指集群中任何一个节点的故障都不会影响用户使用，连接到故障节点的用户会被自动转移到健康的节点。

Oracle RAC的Failover按照实现机制的不同可以分为三种，分别是如下：

1）     Client-Side Connect Time Failover

这种Failover的特点从它的名字“Connect time”就可以看出来，它只在建立连接的那一时刻起作用。换句话说，这种Failover的方式只在发起连接时才去感知节点故障，如果发现服务端节点没有响应，则自动尝试连接地址列表（tnsname.ora）中的另一个地址。一旦连接建立之后，节点出现故障不会做处理，客户端的表现就是会话断开，用户程序必须重新建立连接。

2）     Transparent Application Failover(TAF)

通过对Client-Side Connect Time Failover的特点分析可以看出，这种Failover的意义十分有限。所以从8.1.5版本开始Oracle引入了新的Failover机制-TAF。所谓TAF，就是连接建立以后、应用程序运行过程中，如果某个节点发生故障，连接到这个节点上的用户会被自动迁移到其他的健康节点上。这对于应用程序来讲，这个迁移过程透明、不需要用户的介入，但会导致用户未Commit的事务回滚。相对于第一种Failover机制导致的用户程序被中断，抛出连接错误，用户必须手动重新的种种不便来讲，TAF确实有效得多。

TAF主要通过VIP(虚拟IP)来判断服务节点故障，使用真实IP时，Oracle客户端靠“TCP/IP协议栈超时”来判断服务器故障。TCP/IP协议栈是OS Kernel的一部分，不同的OS有不同的阀值，用户获悉数据库异常的时间完全取决于OS Kernel的实现，虽然有些OS允许修改这个阀值，但是会对其它程序产生未知影响。因此，Oracle RAC引入了VIP，从而避开对TCP协议栈超时的依赖。对于利用VIP来判断服务节点故障的详细原理与机制可以参考《大话Oracle RAC》85页。

TAF主要有两种自动连接方式，一种称之为BASIC，是指在感知到节点故障时才创建到其他节点的连接。另一种称之为PreConnect，是指在建立连接时就预先建立多个到其他节点的连接，当放生故障时可以立即切换。它们之间的不同在延时、资源消耗两个方面有所体现。

3）     Server-Side TAF

Server-Side TAF相对于在客户端进行配置的TAF方法来讲，实际就是解决了一个配置文件（tnsnames.ora）一致性问题。如果有很多客户端使用同一个数据库集群，那么每次这个数据库集群的一个微小调整都有可能带来一次所有客户端配置文件全都要修改的问题，即低效又易出错。Server-side TAF在服务端维护一个统一的配置信息，通过分发（待验证）来达到这一目的。

实际上TAF在客户端实现的就是一个自动连接的机制，而在后台集群中所做的工作却不止这些，服务器集群通过互相发送心跳来监视那些宕机的节点，并且利用VIP的飘移来达到对故障节点的快速判断，从而使客户端快速做出TAF动作。但必须要再次强调的是，在宕机-切换的过程中，用户未Commit的事务会回滚。

3. 并行处理实现机制

疑问1:数据的整合由谁负责？服务器端还是客户端？

疑问2:请求的拆分由谁负责？服务器端还是客户端？

2. ASM简介

1)  定义

ASM 全称是Automatic Storage Management，它是 Oracle 数据库 10g 中一个非常出色的新特性，它以平台无关的方式提供了文件系统、逻辑卷管理器以及软件 RAID 等服务。ASM 可以条带化和镜像磁盘，从而实现了在数据库被加载的情况下添加或移除磁盘以及自动平衡 I/O 以删除“热点”。它还支持直接和异步的 I/O 并使用 Oracle9i 中引入的 Oracle 数据管理器 API（简化的 I/O 系统调用接口）。

ASM 不是一个通用的文件系统，并只能用于Oracle 数据文件、重做日志以及控制文件。ASM 中的文件既可以由数据库自动创建和命名（通过使用 Oracle 管理文件特性），也可以由 DBA 手动创建和命名。由于操作系统无法访问 ASM 中存储的文件，因此对使用 ASM 文件的数据库执行备份和恢复操作的唯一途径就是通过恢复管理器 (RMAN)。

2)  特点

A.   提供非Posix语义的文件系统

B.   提供LVM逻辑卷管理器

C.   提供软RAID功能

D.   自平衡，

E.   安全高效的数据备份恢复软件RMAN

四． 中心数据库部署情况

1. 基础设施相关信息

1) 主机相关信息

2) 操作系统相关信息

3) 网络相关信息

4) 存储相关信息

2. 网络结构图

3. 存储结构图

五． 总结

在这次学习总结报告中，绝大部分对于RAC的理解都来自于张晓明编著的《大话Oracle RAC》一书，书中有许多精彩的地方并没有提到，都是一些很重要的概念或机制，如果全部写上的话会显得过于冗繁，而且不过是转述作者的话而已，但不写实在可惜，所以我决定采取折中方案，将我认为重要的地方与书中的对应页数关联起来在尾页中列出来，以供参考。尤其是书中的第四章-RAC原理，如果想深入理解的话，需要对这章内容仔细阅读。关于本学习总结中关于数据库介绍的部分，都是我的个人理解，必定会存在不准确或不恰当的地方，烦请阅读本学习总结的同事给予指正，十分感谢。另外关于RAC的并行处理机制，连日在网上找资料，并没有取得很好的效果，综其原因，我个人认为用RAC的人，多数是看重其提供的高可用性与负载均衡能力，所以相关资料较少，这块就暂且不写了，且把问题记在心里，日后如有机缘，再补上。

   以下是我列出的我认为较为重要的章节：

1.  集群节点的扩展与集群事务处理并发能力的关系。P67-2.7.2

2.  ClusterWare的概念，它与RAC的关系。P69-前三段

3.  RAC集群环境中的特殊问题：并发控制与DLM、脑裂、IO隔离。P59-60

4.  并发访问带来的数据一致性问题：脏读、不可重复读、幻影读。以及SQL标准中定义的四种隔离级别（数据一致性级别）及Oracle中支持的隔离级别详解。P91-94

5.  Oracle单实例的并发控制机制与RAC集群模式下的并发控制机制。P94-113