电信计费系统毕业设计.docx

毕业设计RAC集群环境下电信计费系统数据迁移的设计与实现 学生姓名：袁洋 学号：068109160 学院：软件学院 专业：软件工程 指导老师：李海波 日期：2013.4.28目录第一章绪论11.1 课题研究的背景和意义11.2 RAC集群的现状1第二章 ORACLE RAC实时应用集群42.1 什么是RAC集群42.2 RAC的基本原理62.3 RAC的组成结构102.4 Clusterware与RAC14第三章 电信计费系统243.1 什么是电信计费系统243.2 背景243.3 改进253.4 意义26第四章 RAC实时应用集群搭建284.1 Oracle RAC的安装环境284.1.1 硬件环境284.1.2 软件环境304.1.3 Oracle RAC的实验环境304.2 Oracle RAC的任务列表314.3 Oracle RAC的任务规划324.3.1 主机配置与软件规划324.3.2 网络规划及时间同步规划344.3.3 存储方案选型354.4 Oracle RAC的实施规划404.4.1 安装RedHat Enterprise Linux 5.4(AS)系统404.4.2 配置Linux主机节点444.4.3 创建并配置第二台Linux主机节点584.4.4 配置各节点的信任关系624.4.5 安装CRS集群软件634.4.6 安装Oracle Database数据库软件704.4.7 配置数据库监听服务Listener714.4.8 创建ASM存储方案734.4.9 创建数据库实例784.5 添加第三节点874.5.1 第三节点添加前准备884.5.2 安装与配置CRS集群件914.5.3 安装Oracle 软件944.5.4 添加新Instance954.6 Oracle RAC的客户端测试964.6.1 验证更新后的RAC集群964.6.2 数据的导入994.6.3 修改归档模式1054.6.4 客户端配置1104.6.5 透明的故障切换1124.6.6 负载均衡116第五章 数据迁移1185.1 将windows上的数据库传输到linux平台1185.2 将数据迁移到Rac集群环境下124第六章总结140参考文献141摘要：作为IT系统的核心, 数据库服务器系统应具有极高的可靠性, 以保证应用系统能够及时的访问到数据库中的数据. 相较而言，数据安全、性能、可用性、可伸缩性、平台无关性以及低价格导致对于传统数据库应用的要求也越来越高。RAC的出现成功解决了传统数据库应用中所面临的这一问题。因而高性能与高可用性的RAC集群数据库服务器成为一种潮流。RAC是Oracle 9i数据库中采用的一项新技术，它可以支持24 x 7小时有效的数据库应用系统，可以再低成本的服务器构成的高可用性系统上自由部署应用，而无需更改底层的应用程序。本项目中，设计与优化方案是一套基于电信计费系统应用系统的后台数据库的支持，通过展现集群数据库与单节点数据库的性能差异以及集群数据库的实时高可用性来反映集群数据库的优势和海量数据的实时变化搭建集群的必要性，然后完成从单节点数据库到rac集群的海量数据的迁移。预期目标如下：1、对电信计费系统的数据库信息进行采集分析；2、对采集到的数据进行分析，并根据相应分析结果进行数据间关系的设计；3、从后台逻辑设计到使用阶段的数据库的优化；4、用window系统模拟一台外部存储设备海量数据迁移到rac集群中5、模拟数据库集群成员故障，检测集群的实时高可用性。关键词：实时应用集群；集群；ASM存储；高可用；高性能；数据迁移Design and Implementation of the telecommunications billing system Data Migration RAC environmentAbstract：As the core of the IT system, the database server system should have high reliability, in order to ensure the application system can timely access to data in a database.In contrast, data security, performance, availability, scalability, platform independence and low prices lead to traditional database application requirements are also getting higher and higher. RAC has successfully solved the traditional database application in the face of this problem. The high performance and high availability cluster RAC database server as a trend.RAC Oracle9i database is a new technology used in, it can support24x 7 hours effective database application system, can be low cost server high availability system free to deploy applications, without changing the underlying application.In this project, the design and optimization of program is a set of back-end database application system based on telecommunications billing system support, through real-time high availability to show the difference in performance of the cluster database with a single-node database cluster database to reflect the strengths and mass of the cluster databasereal-time data changes need to build a cluster, and then completed the migration of the vast amounts of data from the single-node database cluster to rac. The targets are as follows:1, acquisition and analysis of telecommunications billing system database information;2, on the data collected for analysis and the design of the relationship between the data according to the corresponding analysis results;From the background logic design to the optimization of the use phase of the database;Window system to simulate an external storage device mass data migration rac cluster5, real-time simulation database cluster member failure detection cluster high availability.Key words： Real Application Cluster(RAC); Cluster; ASM Storage; High-availability; High-performance；Data Migration 144 / 151第一章 绪论1.1 课题研究的背景和意义数据库的性能调整与优化对于整个生产系统的正常运行起着至关重要的作用。随着企业数据的不断扩展,单实例数据库已经不能满足要求,于是产生了数据库高可用性集群技术。从而,对于如何使用数据库集群技术,如何保障数据库高可用性集群技术在生产系统上面有很好的应用就成为了数据库研究的一个重要课题。长期以来，在业界流行着这样一个“潜规则”：以是否有RAC经历来衡量DBA水平。虽然并不十分的准确，但某种程度上反映了RAC在Oracle金字塔的顶尖地位。造成这种现象的原因有很多，作为一种高端解决的方案，RAC在实施成本一度都是很高的，除开硬件成本，OS License，Oracle License成本，还包括第三方的Cluster软件成本，人力成本，因此RAC案例一直集中在电信，银行，制造等大企业，中小企业鲜有问津，绝大多数的DBA很难有机会接触到这种环境。RAC的神秘很大程度上要归功于“高墙锁深宫”，技术本身的因素反而成为了次要。但随着芯片技术的发展，近年来硬件成本不断的降低，物美价廉的PC Server越来越深入人心。在软件方面，更多的企业已经在核心业务上选择Linux作为首选平台，Oracle尤其重视在Linux平台上的应用，它也是第一个支持Linux平台的商业数据库。Oracle在10g版本推出的同时提供RAC的“一站式”解决方案，包括针对存储的ASM，针对集群的Clusterware。因此在Oracle 10g上部署RAC成本非常的低廉-不需要昂贵的小型机和专有系统(当然，小型机和PC Server上还是有很大的差距的)，普通的PC Server + Linux就可以胜任；不需要再采购第三方的集群软件，存储软件，不需要第三方的人力资源，只需要一个DBA就可以完全搞定。Oracle RAC是可以支持24 x 7 有效运行的数据库应用系统，在低成本服务器上构建高可用性数据库系统，并且自由部署应用。在Oracle RAC环境下，Oracle集成提供了集群软件和存储管理软件，为用户降低了应用成本。当应用规模需要扩充时，用户可以按需扩展系统，以保证系统的性能。随着rac环境的应用增多，数据迁移也随之而来，尤其是海量数据的迁移更为困难和繁琐。1.2 RAC集群的现状在过去近40年时间里，Oracle公司从一家普通的数据库产品开发和销售公司成长为业界广泛认可的数据库产品领导者。今天数据系统已经成为了企业的重中之重，而企业对数据库的可用性要求也越来越高。随着数据库系统高可用性理论日趋成熟，它也越发的被重视。无论是国内还是国外的IT界都加快了对HA技术和HA框架的研究。但相对而言，国内在数据库研究(如HA)的发展还相对的落后，不论是软件上还是硬件上，HA解决方案都是被国外厂商所领导，他们凭借早期的研发能力，雄厚的资金支持以及完善的产品链，推出了诸多不同层次，各具特色的高可用性解决方案。像HP、EMC、IBM等公司都在商务主机和存储的层面提高了数据库系统的可用性。作为数据库系统，一般都会有自己的HA的实现方法和解决方案，Oracle公司在这方面一直都极为的重视，在多年的创新基础上，2004年推出的Oracle10g引入了众多新的可用性和数据保护技术与解决方案，RAC、DataGuard、Flashback、RMAN等为客户提供了更加有效的方法来实现企业数据和应用最大化的可用性。就国内而言，近年来，各行业都开始借鉴国外经验使用高可用的方案来解决存储，数据的问题。由于我国在软硬件技术和系统架构上与发达国家存在较大差距，国内所使用的高可用性解决方案大部分都采用国外的产品，在已经建成并投入使用的高可用性框架也存在功能单一，投入成本高，投资回报率低，结构复杂，管理成本居高不下等问题。当然，这个问题也在慢慢的得到了解决，现在的中小型企业所采用的基于PC的RAC就可以很好的解决。相信在未来的一段时间，更多的国人的HA方案会得到应用与发展。第二章 Oracle RAC实时应用集群2.1 什么是RAC集群集群是一种计算机系统，通过一组松散的计算机软件和硬件连接起来高度紧密地协作完成计算工作，某种意义上可以看作是一台计算机。集群系统中单个计算机通常称为节点，以网络连接(或其它方式)。集群常用来改进单个计算机的计算速度和可靠性。一般情况下集群计算机比单机，如工作站或超级计算机性能价格比要高得多。而集群都具有共通的特点：通过多台计算机完成同一个工作，达到更高的效率；多机的内容，工作过程等完全一致(HP，IBM的Unix商务机略有不同)，如果一台死机，余下的仍可代替。根据不同的功能可以将集群分为如下的四类：高性能计算集群(High-performance，HPC)采用将计算任务分配到集群的不同计算节点而提高计算能力，主要应用在科学计算领域。负载均衡集群(Load balancing，LB)通过一个或者多个前端负载均衡器，将工作负载分发到后端的一组服务器上，从而达到整个系统的高性能和高可用性，也被称为服务器群(Server Farm)。在高可用性集群和负载均衡集群中会使用类似的技术。高可用性集群(High-availability，HA)当集群中某节点失效时，其上的任务会自动转移到其他正常节点上，可以将集群中的某节点进行离线维护再上线，该过程并不影响整个集群的运行。网格计算(Grid computing)网格计算或网格集群是一种与集群计算非常相关的技术。与传统集群相比，网格是连接一组相关却不信任的计算机，它的运作更像一个计算公共设施而不是一个独立的计算机，通常比集群支持更多不同类型的计算机集合。网格计算是针对有许多独立作业的工作任务作优化，在计算过程中作业间无需共享数据，主要服务于管理在独立执行工作的计算机间的作业分配。资源如存储可以被所有结点共享，但作业的中间结果不会影响在其他网格结点上作业的进展.现在经常使用的集群软件主要有：Sun Grid Engine；SLURM(天河一号的Job Scheduler)；JBoss Application Server；Lander Vault；Solaris Cluster；IBM HACMP；Oracle Real Application Cluster，RAC。图2.1 RAC集群拓扑图如图2.1所示，双节点的RAC拓扑从逻辑上显示了RAC集群的层次结构。RAC集群由多个服务器节点组成，而节点间通过心跳线连接，每个节点上都运行着一个或多个Instance，实例之间通过集群中间件的协助，共同操作一个数据库。所有的服务和程序通过操作系统都去访问一个共享存储，最终完成数据的读写。用户所看到的仅仅只有一个数据库。2.2 RAC的基本原理1. RAC的原理核心RAC是一个具有共享缓存体系结构的集群数据库，本质上还是一个关系型数据库，克服了传统的共享磁盘方法的限制，为所有业务应用程序提供了一种可伸缩性和可用性的数据库解决方案，一般与Oracle Clusterware或第三方集群软件共同组成Oracle集群系统。作为数据库管理系统而非数据存储，最大的区别就是数据库系统提供了最大程度的并发访问-并发读取和并发修改。因RAC是运行于多台计算机的数据库，并发也从单机的多进程间并发发展到了多机上的多进程并发。对于这种并发问题，RAC通过分布式锁管理器(Distributed Lock Management，DLM)解决。DLM拥有仲裁的能力，记录哪个节点正在使用哪种方式操作哪种数据，并负责协调和解决节点间的竞争。RAC集群的最核心的功能Cache Fusion(内存融合)是Oracle 9i时引进的新技术，它将所有的SGA虚拟称为一个大的SGA区域，通过高速私有网络，进行实例间数据块传递(Cache Fusion前提，网络的速度比磁盘访问的速度快)。每当有不同的实例请求相同的数据块的时候，这个数据块就在实例间进行传递。Cache Fusion通过互联网络在集群内各节点的SGA之间进行块传递，避免先将块送到磁盘，再重新读入到其他实例的缓存中的低效方式。图2.2 Cache Fusion的示例Cache Fusion把每个节点的内存逻辑看成一个大的SGA，然后通过网络来提供物理传输。当节点请求一个块时，不从磁盘中读取，而是向GCS服务发出请求Resouce Master(存放当前哪些实例持有哪些块的信息)，Resource Master所在的实例请求当前持有块的实例向发出请求的实例传输块。当一个块被读入RAC环境中某个实例的缓存时，该块会被赋予一个锁资源，以确保其他实例知道该块正在被使用。若另一个实例请求该块的一个副本，而该块已经处于前一个实例的缓存内，那么该块会通过互联网络直接被传递到另一个实例的SGA。如果内存中的块已经被改变，但改变尚未提交，那么将会传递一个CRS副本。这意味着只要可能，数据块可在各实例的缓存之间无需写回磁盘的移动，避免了同步多实例的缓存所花费的额外I/O。不同的实例缓存的数据可以是不同的，也就是在一个实例要访问特定块之前，而它又从未访问过这个块，那么它要么从其他实例Cache Fusion，或者从磁盘中读入。可以看出，Cache Fusion资源实际上就是一个个的数据块的映射。对于Cache Fusion而言，每一个数据块都会被映射成一个Cache Fusion资源，这实际上是一个数据结构，资源名就是数据块的地址(DBA)。每个数据的请求动作时分布完成的。针对资源性质的不同，RAC将共享资源从性能上分成两类，Cache Fusion Resurce和Non-Cache Fusion Resource，对于不同的资源使用不同的锁机制。2. RAC集群环境中的几个关键问题并发控制。这个问题已经在前面解决了。健忘症(Amnesia)。集群环境配置文件通常都不是集中存放，而是每个节点都有一个本地副本，在集群正常运行时，用户可以在任何节点更改集群的配置，并且这种更改会自动同步到其他节点。但也可能会出现这种情况：一个双节点集群，节点A因正常维护而关闭，然后再节点B上修改了某些配置文件，然后关闭节点B，并启动节点A，此时节点B的修改是无法同步到节点A上的，因此节点A使用的仍然是老的配置文件，这种情况下，修改的配置文件是丢失的，就是所谓的健忘症.脑裂(Split Brain)。在集群中，节点间都是通过心跳了解彼此的健康状态，以确保各节点协调工作。这里作一个假设，假设心跳出现问题各个节点还在正常运行。这时，每个节点都认为其他的节点宕机了，自己是整个集群环境中的“唯一存活者”，自己应该获得整个集群的控制权。在集群环境中，存储设备的共享也就意味着数据的不完整性，也即是数据灾难，这就是“脑裂”。脑裂的后果是很严重的：共享资源被瓜分，两边服务都宕掉；或双方服务都启动，但同时读写共享存储，导致数据损坏(如数据库轮询的联机日志出错)。对HA系统“裂脑”，通常使用投票算法(Quorum Algorithm)。原理如下：集群中各个节点以心跳机制通报彼此的健康状态，设每收到一个节点的“通报”代表一票。对3个节点的集群，A心跳出现问题后，B和C是一个partion，有2票，A只有1票。按照投票算法，B和C组成的集群获得控制权，A被剔除。那么就由节点B和节点C组成的新集群来继续对外提供服务；但如果只有2个节点，投票算法就失效了。此时，就引入了第三个设备：Quorum Device，它通常使用共享磁盘，也叫作Quorum disk。这个Quorum Disk也代表一票，当2个节点心跳出现问题时，各节点同时去争取Quorum Disk这一票，最早到达的请求被最先满足。故先获得Quorum Disk的节点就获得2票，余下节点就被剔除。除此之外大概有以下几种对策：1) 添加冗余的心跳线。尽量减少“裂脑”发生机会；2) 启用磁盘锁。正在服务一方锁住共享磁盘，“裂脑”发生时，让对方完全抢不走共享磁盘资源。但如果占用共享盘的一方不主动解锁，另一方就永远得不到共享磁盘。若服务节点突然死机或崩溃，就不能执行解锁命令，后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了智能锁(正常节点只在发现心跳线全部断开时才启用磁盘锁)；3) 设置仲裁机制。如设置参考IP(如网关IP)，当心跳线完全断开时，各节点都ping参考IP，不通则表明断点就出在本端，那就主动放弃竞争，让能够ping通的一端去启服务。更保险的作法，ping不通的一方自我重启，以释放可能还占用着的那些共享资源。实际上正常情况下脑裂是无法见到的，现代集群都有保护机制来避免这种情况发生，但也不得不防。照官方的说法，如果你跑生产，要保证数据不受损坏，就必须有隔离设备。IO隔离(IO Fencing)。当集群系统出现“脑裂”问题的时候，可以通过投票算法来解决谁获得集群控制权，谁应该被赶出集群。而且还必须保证被赶出去的结点不能操作共享数据。因为此时该节点很有可能还在运行当中，如果不加以限制，那么很可能会修改共享数据。这就是IO Fencing要解决的问题。IO Fencing的实现有硬件和软件2种方式：对支持SCSI Reserve/Release命令的存储设备，可以用SG命令来实现，正常的节点使用SCSI Reserve命令“锁住”存储设备，故障节点发现存储设备被锁住后，就知道自己被赶出了集群，也就是说自己出现了异常情况，就要自己进行重启，以恢复到正常状态，也叫Sicide(自杀)机制(即所谓的软件方式)，Sun和Veritas使用的就是这种机制；而硬件方式STONITH(Shoot The Other Node in the Head)是直接操作电源开关，当一个节点发生故障时，如果另一节点能侦测到，就会通过串口发出命令，控制故障节点的电源开关，通过暂时断电再上电的方式使故障节点被重启动，当然，这需要硬件支持。CRS采用的是软件方式，直接重启故障节点。事实上，无论采取哪种方式，其目的都是相同的：保证故障节点不能再访问共享数据。2.3 RAC的组成结构1. RAC集群的逻辑结构Oracle术语中实例和数据库是两个不同的概念，实例是指由SGA和后台进程组成的实时运行环境，是动态概念；而数据库特指数据文件，控制文件和日志文件这些永久保存在存储设备上的文件，是静态概念。Oracle的实例和数据库是一对一或多对一关系，这个不容易区别 (Oracle的架构中都要区分，虽然许多时候二者可以互换)。从图2.1可以看出RAC集群由存储层，网络层，集群件层，应用层组成。存储层。虽然在RAC系统中有多个实例，但是只有一个数据库运行在共享磁盘上，数据文件，联机日志，控制文件等文件在集群中都只有一份(镜像不算)。所有的RAC节点平等使用这些文件。网络层。在RAC集群环境中，有三个网络：Public网络，用于对外提供数据查询服务；Private网络，用于RAC心跳和Cache Fusion；第三个则是存储设备和与之配套的网络设备(生产环境中一般是光纤交换机和每个节点的HBA卡)。前二者用于传输网络数据，而第三个用于传输SCSI数据.集群层。单机环境下，Oracle运行在OS内核之上，OS内核负责管理管理硬件设备，同时提供硬件访问接口。Oracle通过OS内核来实现对硬件的调用请求。在集群环境下，存储设备共享。因普通OS内核只能控制单机上多进程的访问，无法实现多主机间的协调工作。此时，就引入额外的控制机制，在RAC中，这个机制就是位于Oracle和OS内核之间的Cluseterware，Clusterware会在OS内核之前截获请求，然后和其它节点上Clusterware协商，最终完成上层的请求.图2.3 集群层位置示意图Oracle 10g前，搭建RAC所需要的集群软件依赖于硬件的生产厂商，也导致RAC超高的价格比的产生。Sun、HP等公司都有自己的集群件产品，也有许多如Veritas的第三方Clusterware产品。在不同的平台上实施RAC需要先安装和配置厂商的集群软件，而Oracle公司只提供Linux、Windows两种平台上的集群软件Oracle Cluster Manager，这种环境无论是对DBA还是系统管理员都是极大的挑战。从10.1.0版本推出平台中立的集群产品CRS(10.2.0版本时更名为Oracle Clusterware)开始，RAC不再依赖于厂商的集群软件(Oracle仍支持厂商提供的集群软件，仅Linux平台上才必须选择CRS)。CRS支持对其他集群产品的集成，其他软件都可以借助其API而轻易的实现集群功能。通常意义上可以认为CRS = Clusterware = Oracle Cluster Ready Service = Oracle Cluster Software.应用层。集群环境之所以能够提高可用性，是因为CRS对运行其上的应用进行监视，并在发生异常时进行重启、切换等进行操作。这些被CRS监控的对象就叫做CRS Resource，应用层由若干的CRS Resource组成。CRS Resource可以理解为一个进程或一组进程组成的一个完整服务。这些CRS Resource是在RAC安装时创建并注册到CRS中，以元数据(metadata)形式被记录在OCR磁盘上，这些元数据包括CRS Resource的名称、如何启动、停止、如何检查健康状况等配置信息。2. RAC集群的体系架构在图2.4和图2.5中，与传统单实例架构相比，RAC Instance的SGA最显著的变化是多出了一个Global Resource Directory部分。图2.4 传统的Single-Instance架构图2.5 RAC架构Oracle操作都是在内存SGA中完成的，而RAC的每个数据块在任何一个Instance的SGA中都存在着一份拷贝，RAC必须知道这些拷贝的分布、版本、状态，GRD就是这种信息的内存区域。虽然GRD位于SGA中，但由于RAC拥有多个SGA，因此所有节点的GRD加在一起才是完整的GRD。而在后台进程上，除了传统单实例相同的DBWR，LGWR，ARCn，CKPT等进程之外，每个Instance 都增加了若干的RAC专有的进程，需要注意的是，这些进程的名称和它们所提供的服务的名称差异极大。例如：LMSn，Global Cache Service(GCS)，Cache Fusion主进程，负责数据块在实例间的传递；LMD，Global Enqueue Service(GES)，在多个实例之间协调对数据块的访问顺序，确保数据的一致性访问，与GCS服务和GRD构成RAC的核心功能Cache Fusion；LCK，负责Non-Cache Fusion资源同步访问，每个实例都有一个LCK进程；LMON，Cluster Group Services(CGS)，负责每个实例的LMON进程定期的进行通信，从而检查与维护集群中各个节点的状态；GSD，负责从客户端工具接收用户命令，为用户提供管理接口；DIAG，监控实例的健康状态，实例运行错误时将诊断数据记录在Alert.log日志。RAC文件大都放置在共享存储上；每个实例都有自己的undotbs和redo log，每套redo log都叫做一个Redo Thread，每个Redo Thread至少要两个Redo Log Group，每组有两个以上的成员，放在不同的磁盘中；每个实例都会产生自己的归档日志(可不放在共享存储上，但若在单个实例上进行备份归档日志或进行Media Recovery操作，却要求在该节点必须能够访问所有实例的归档日志)。2.4 Clusterware与RACRAC的网络层和存储层是硬件资源，集群层和应用层则对应软件资源。而集群层则是由集群软件组成，它负责协调每台主机的多进程的共享使用，以及协助主机间进程的共享使用。1. Clusterware与RAC在整个的RAC环境中，实际上有两个集群环境存在。Clusterware所组成的集群和Database所组成的数据库集群。前者负责管理这个集群环境中的硬件资源，并为上层的Database集群提供基础服务。可以说，Clusterware是将所有的节点虚拟成了一台计算机的操纵系统内核，而RAC就是将所有节点上的实例虚拟成为一个实例的Database应用。2. Clusterware的组成结构当安装完Clusterware软件后，每个节点上的CRS就会自动启动。Oracle的Clusterware运行环境由三大部分组成：两个磁盘文件，后台进程以及网络元素。1) OCROCR与Votingdisk是CRS解决健忘和脑裂的应对之法。这是两个磁盘文件，必须存放在共享存储上。CRS解决健忘的办法：将配置文件存放在共享存储上，各个节点共用一份配置文件，从而确保修改不会丢失。OCR中保存了集群的配置信息，并以Key-value存放这些信息(10g前，叫Server Manageability Repository，SRVM)。OCR磁盘文件大小约100MB，Clusterware安装时，会指定OCR位置，该位置将被记录到/etc/oracle/ocr.loc(9i是srvConfig.loc)。Oracle启动时，根据ocr.loc中内容从指定的位置读入OCR的信息。本设计中ocr.loc的文件内容如下：ocrconfig_loc=/dev/raw/raw4ocrmirrorconfig_loc=/dev/raw/raw5local_only=FALSE可以看出，OCR的存放位置是/dev/raw/raw4，冗余镜像位置是/dev/raw/raw5，且存储的模式是共享存储。表2.1 OCR Key的属性(通用的)属性名含义VALUE_TYPE值的类型VALUE值USER_NAME这几个属性共同定义了该Key所需要的操作权限.GROUP_NAMEUSER_PERMISSIONGROUP_PERMISSIONOTHER_PERMISSIONOCR主要由OCR key和OCR进程组成。OCR信息在结构上是一个有着3大分支的树形结构(SYSTEM、DATABASE、CRS)。而这些信息仅能被root用户所修改，可使用ocrdump命令导出。设计中的OCR分支的结构如图2.6、图2.7、图2.8所示，key的CRS部分因子项过多(1000余项)，仅列出前3级的Key。图2.6 OCR的SYSTEM拓扑图图2.7 OCR的DATABASE拓扑图图2.8 OCR的CRS拓扑图虽然Clusterware要求每个节点都能访问和修改OCR，但在Clusterware的运行过程中，并不是每个节点都能同时操作OCR共享磁盘的。在每个节点的内存中都有一份OCR内容的拷贝，这份拷贝叫作OCR Cache。 每个结点都有一个OCR Process来读写OCR Cache，但只有一个节点的OCR process能读写OCR Disk中的内容，这个节点叫作OCR Master结点。这个节点的OCR process负责更新本地和其他结点的OCR Cache内容。图2.9 OCR Process如图2.9，所有需要OCR内容的其他进程，比如OCSSD，EVM等都叫作Client Process， 这些进程不会直接访问OCR Cache，而是向OCR Process发送请求，借助OCR Process获得内容，如果想要修改OCR 内容，需要该节点的OCR Process向Master node的OCR process提交申请，由Master OCR Process完成物理读写，并同步所有节点OCR Cache中的内容。2) VotingdiskVoting Disk作为表决磁盘文件主要记录节点成员状态，在出现脑裂时，仲裁哪个节点可以获得集群的控制权，而其他的节点必须从集群中剔除。CRS使用两种心跳设备来验证节点成员的状态：一是表决磁盘，集群同步服务进程每隔指定的最大时间段都会向表决磁盘写入一条心跳信息，集群通过表决磁盘即可验证节点的状态，如果某个节点在内没有向表决磁盘写入信息，集群就认为此节点失效，而执行故障切换。另一心跳是节点间私有以太网的心跳，通过这个心跳机制可以判断节点间是否出现了网络故障。两种心跳机制的结合，有效的增加了集群的可靠性。在安装Clusterware时也会指定这个位置。一般情况下，Votingdisk都分配100MB的空间。3) CRS的后台进程与服务Oracle Clusterware由若干进程组成，最重要的3个是：CRSD、CSSD、EVMD。CRS安装后会在每个节点执行root.sh脚本，它会在/etc/inittab的最后将三个进程加入，以后系统启动时，CRS会自启，若EVMD和CRS出现异常，系统会自动重启这两个进程，但如果CSSD异常，系统会立即重启.Clusterware的后台进程可以总结如下：表2.2 Clusterware进程Oracle Clusterware ComponentLinux/Unix进程Windows服务Windows进程Cluster Synchronization Services (CSS)Init.cssdocssdocssd.binOracleCSServiceocssd.exeCluster Ready Service (CRS)orsd.binOracleCRSServicecrsd.exeEvent Manager ServiceevmdevmdloggerOracleEVMServiceevmd.exeevmlogger.exeOracle Notification Service (ONS)Onsons.exeProcess Monitor DaemonOprocdOraFenceServiceRACGracgmainracgimonracgmain.exeracgimon.exeOCSSD是CRS最关键的进程，提供CSS服务。如果出现异常，会导致系统重启。CSS有2种心跳机制，Network Heartbeat和Disk Heartbeat，提供脑裂保护等基础集群服务功能，都有最大延时。对Disk Heartbeat，这个延时叫作IOT(I/O Timeout)；对Network Heartbeat，这个延时叫MC(Misscount)。缺省IOT大于MC，默认由Oracle 自动判定的，并不建议手工调整。可以通过如下命令来查看参数值：oraclerac-db1 $ crsctl get css disktimeoutoraclerac-db1 $ crsctl get css misscount单节点环境使用ASM同样会用到这个进程，用于ASM实例和RDBMS实例的通信。若在使用ASM的节点搭建RAC，节点要求只有一个运行在$ORA_CRS_HOME下的OCSSD进程，此时要先停ASM，并通过$ORACLE_HOME/bin/localconfig.sh delete删除之前的inittab 条目。CRSD是HA主要实现进程，提供CRS服务。Clusterware是位于集群层的组件，为应用层资源CRS Resource提供HA服务，它必须监控集群资源，并在资源运行异常时进行干预，包括关闭，重启进程或者转移服务。RAC会在安装的时候，以CRS Resource的形式注册需要高可用性的组件到OCR中，CRSD根据OCR的内容，决定监控哪些进程，如何监控，出现问题时又如何解决。也就是说，CRSD负责监控CRS Resource的状态，并要启动、停止、监控、Failover这些资源。默认CRS会自动尝试重启资源5次，如果还是失败，则放弃尝试。CRS Resource包括GSD、ONS、VIP、database、Instance和 Service。而这些资源又可以被分成2类：GSD、ONS、VIP 、Listener属于Noteapps类；database、Instance、Service属于Database-Related Resource类。其中GSD、ONS和VIP是在OCR的安装过程自动创建并注册的，而Listener、Database、Instance和Service可在安装过程中自动创建, 也可在安装成后使用dbca, netca和srvctl等工具手工创建和注册.EVMD负责发布CRS产生的Event，通过ONS和Callout Script(回调脚本)发布给客户。可以自定义回调脚本，放在特定的目录，当有某些事件发生时，EVMD自动扫描该目录，并调用用户脚本，这种调用是通过racgevt进程完成的。除了发布事件之外，EVMD还是CRSD和CSSD两个进程之间的桥梁。CRS和CSS之间的通信就是通过EVMD进程完成的。RACGIMON负责检查数据库健康状态，Service的启动、停止、故障转移(Failover)。它会建立到数据库的持久连接，定期检查SGA中的特定信息，该信息由PMON进程定时更新。OPROCD也叫Process Monitor Daemon。在非Linux平台且没有使用第三方的集群软件时，可以看到这个进程。这个进程用来检查节点的Processor Hang(CPU 挂起)，如果调度时间超过1.5秒，就认为CPU工作异常而重启节点。也就是说这个进程提供IO隔离的功能。在Linux 平台上，是利用Hangcheck-timer模块来实现IO隔离的。4) VIP原理与特点RAC节点的两个NIC一块和其他的应用服务器或客户机连接，提供对外的数据服务；另一块连接到一个私有的交换机上，提供节点间的通信。通信的内容包括Network Heardbeat和Cache Fusion。之所以分开Public NIC和Private NIC，是因为Private NIC上传递的是大数据量，低延迟的内容，很容易占用Public NIC的带宽，并且集群的可靠性也得不到保证。Oracle的TAF就是建立在vip之上的。IP是利用TCP层超时，vip利用的是应用层的立即响应。vip它是浮动的IP。当一个节点出现问题时会自动的转到另一个节点上。图2.10 浮动的vip用一个例子来说明：假设有一双节点的RAC，正常运行时每个节点上都有一个vip：vip1和vip 2。当节点2发生故障。RAC会做如下操作：1) CRS检测到rac2节点异常后，触发Clusterware重构，把rac2节点剔除集群，节点1成为新的集群；2) RAC的Failover机制把节点2的vip转移到节点1，节点1的public网卡上就有3个IP地址：vip 1，vip 2，public ip1；3) 用户对vip 2的连接请求会被IP层路由转到节点1；4) 因节点1上有vip 2的地址，数据包会顺利通过路由层、网络层、传输层；5) 但节点1只监听vip 1和public ip1两个ip，并没有监听vip 2，故应用层没有对应的程序接收这个数据包，这个错误立即被捕获；客户段能够立即接收到这个错误，然后客户段会重新发起向vip 1的连接请求.可以看出，vip具有如下特点：vip通过vipca脚本创建，作为Nodeapps类型的CRS Resource注册到OCR，由CRS维护；vip会绑定到节点的Public NIC上，当某个节点发生故障时，CRS会把故障节点的vip转移到其他节点上；每个节点的Listener会同时监听Public网卡上的Public IP和vip；客户端的tnsnames.ora一般会配置指向节点的vip。3. Clusterware的日志体系CRS只能通过日志和trace文件进行故障诊断，但CRS日志体系相对数据库而言更为复杂。alert.log：类似于数据库的alert.log，一般作为检查的起点；crsd、cssd、evmd：对应CRS的三个同名进程的日志目录；racg：存放所有nodeapp的日志，包括ONS和vip。Client，存放着工具执行日志。Oracle Clusterware提供了如ocrcheck，ocrconfig，ocrdump，oifcfg，clscfg的命令行工具，它们运行时产生的日志就存放在这个目录下。图2.11 Oracle Clusterware的日志体系4. RAC与Clusterware的交互作为集群数据库，除了并发控制，还是一个高可用方案，就是可以根据数据库集群的状态变迁进行自动的重构，这需要数据库与Clusterware的交互来完成(如图2.12)。图2.12 RAC与Clusterware的交互总的来说，Clusterware要决定集群的组成、成员身份、状态。它并不关心上层应用是数据库还是Web应用，它只负责收集集群的节点状态的完整视图并反馈给上层。而RAC依赖于从Clusterware获得这个视图，根据视图来调整自己。事