【微学堂第二期】RAC高可用最佳实践及案例分享
大家好，我叫应以峰，来自于杭州美创科技有限公司，是一家以ORACLE服务为主体的数据库维保厂商，本人热衷于ORACLE技术的研究，目前活跃于ITPUB数据库管理模块下Oracle高可用模块。
今天由我给大家分享关于RAC最佳实践及日常维护性工作，以及几个简单的案例。大家如果对我分享的内容有兴趣或者有疑问，欢迎通过各种方式进行探讨。
本次分享分成3部分：
第一部分主要讲解RAC安装过程中的最佳实践；
第二部分主要讲解RAC日常运维的一些基本工作，及RAC的一些基本概要点；
第三部分主要分享一些经典的故障案例。
学习RAC的几点小建议： 1.本人认为，一个好的DBA不仅需要懂得基本的ORACLE知识，还需要懂得一定的主机、存储、网络等。 2.反复的安装我认为是对于掌握RAC基础的一个很好的模式，当然，所谓的反复安装最好的必然是在生产环境，在各种生产环境中，能碰到各种各样的稀奇古怪的问题，来自存储的，来自网络的，来自主机参数配置的等等。 3.实践，反复的实践各种命令，无论是作为一个专业的乙方单位还是甲方单位，不能等到真的出问题的时候再说：容我先去查个看集群状态的命令。这显然是不可取的，很多简答的命令及相关的参数要做到了熟于胸。 4.模拟各种场景，我们会在稍后的PPT中给出，作为一个希望好好了解RAC的DBA，模拟各种必须的场景是掌握RAC最好的办法，比如日常的更换磁盘组磁盘，更换RACIP 模拟迁移等等。
此处标注一个正常的普通RAC的最简单拓扑图，在这个拓扑图里我们可以看到，在安装RAC中，最少的配置模块。（如下图） 当然以上所谓的最小配置是基于物理隔离的情况下，如果大家觉得负载轻，系统等级不高，也可以考虑通过VLAN的方式共用公网及心跳交换机。 基于上层简单的RAC架构，在5年前，我所在的公司美创科技就已经率先提出全冗余的高可用架构，相比较于之前的普通高可用RAC架构，在对心跳交换机，公网交换机，光交，存储，主机等进行了多层冗余后，该RAC架构可以确保短距离同城跨机房存在，避免因机房断电等一些物理层面的硬件损坏导致数据库停运。 当然该架构还涉及多方面知识点，不是简单的硬件堆积架就可以完成，如何协同处理确保真正故障的时候如何剔除失败的硬件是整个架构的核心解决思路。大量的事实证明，在出现故障的时候，冗余架构还是能够真正起到保障作用的。当然，大家不能把这种冗余架构当成真正的容灾，毕竟，他不能防止逻辑上的误删除，或者认为的误操作等。下图在一个简单安装RAC过程中需掌握的基本技能： 1.在主机环境检查中，需一定的操作系统、存储，网络等方面的知识，如确保操作系统已经完全patch必须的一些包，调整了一些基本的参数，检查存储多路径是否存在问题。 2.检查网络，如果网卡存在双网卡绑定，还需要对网卡的冗余负载进行一系列的测试。 3.系统参数配置：此部分是重点，了解在ORACLE最佳实践中让我们配置的基本参数有哪些，参数作用及参数值的计算方法。 4.Grid rdbms dba建库方面我们就不多涉及，在一套RAC的安装过程中，只要做好了环境检查，参数配置，在这两部，相对发生问题的可能性还是比较小的，很多人在这一步出现问题，最终发现都是因为前期参数配置出现问题。 5.参数优化：参数优化指的是在集群及数据库安装完成后，我们对一些必须的参数进行优化，比如11g一些目前存在BUG较多的新特性，或在打内存大CPU下一些ASM内存进程参数的配置等 。 6.必要的监控工具部署：无论只是单纯的客户一次性安装部署，还是长久的维保客户，必要的监控工具部署我们认为是对客户也是对自身的负责，比如调整AWR间隔，和OSWATCH的部署等。下图是一些摘抄至MOS的RAC安装文档，对于新学习RAC的人员，以上文档还是略有帮助，包括本人，对于最小安装文档，有时候也会定期去看看，是否有新的内容及变化，在这个版块就不耽搁过多的时间，有兴趣的大家可以去参考一下。接下来，主要描述RAC日常的一些基本管理及基本的命令：下图主要描述RAC的一些主要进程： 其实我们通过描述整个集群的启动过程就可以简单描述所有进程的基本功能，这里面进程很多，我们需要掌握哪些是核心进程，哪些是非核心进程，哪些进程出现问题的可能性比较大。 集群的启动过程：ohasd阶段，构建集群阶段，启动资源阶段 第一阶段：调用/etc/inittab文件中的脚本，产生init.ohasd run进程之后，ohasd.bin 进程会被启动，这个时候OLR（Oracle Local Registry）会被访问，并且ohasd.bin进程会启动对应的agents(orarootagent, oraagent, cssdagnet 和 cssdmonitor) 来启动集群的初始化资源。所以说ohasd进程是最关键的守护进程，只有确保该进程启动，后续的进程才能够正常启动。 第二阶段：启动mdnsd等进程，Mdnsd，进程透过多播（Multicast）发现集群中的节点和所有的网卡信息；Gpnpd，发布构建集群所需要的bootstrap 信息，并且在集群的所有节点之间同步gpnp profile；Gipcd，这个进程负责管理集群中所有的私网（cluster interconnect）网卡；Ocssd，进程，这个进程无需多说，集群的心跳进程，也是集群最关键的进程，有时候集群很多的问题都是由于这个进程造成的，当然不是说这个进程问题太多，而是说这个进程太重要；启动其他的初始化进程：ora.ctssd, ora.asm, ora.cluster_interconnect.haip, ora.crf, ora.crsd；Ctssd，集群时钟进程，同步节点时间。 最后一个阶段：在这个阶段，主要是通过crsd进程启动各个资源。该图主要描述RAC的基本日志架构图，想要更好的掌握了解RAC的运行，在掌握RAC的基本进程后，需要详细的知道集群的运行日志在哪里，进程的日志在哪里。只有掌握明确知道这些路径我们才能更好的判断集群故障，解决集群问题。在集群的日常管理中，必不可少的涉及到很多集群的命令，我们需要熟练掌握这些命令，而不是在出现问题的时候再去查看命令的帮助手册。 我们最常用的命令就不用多说了，crs_stat命令，不过这个命令从11g开始已经只能算是一个兼容性命令，以后将逐渐被crsctl命令给取代，从11g开始，我们通过crs_stat 命令并不能很详细的看出集群所有实例的运行状态，包括HAIP等都没有很好的提现。但是作为10g的命令，用习惯了，估计简单的看个集群资源的状态更多的人还是喜欢通过这个命令来看。 crsctl命令，这个命令从11g开始，我只能说，很好，很强大，之前该命令只负责一些关启集群，设置自启动等等一些权限较高的操作。从11g开始强化了10gcrs_stat命令：crsctl status resource –t---》crsctl stat res -t Ocrcheck命令用于检查OCR盘的信息； Asmcmd命令是进入ASM字符交互菜单的一个命令，在该界面中，我们可以不需要通过select等查询视图命令，很好的看到集群管理下的ASM磁盘的多个信息。基本的ASM视图和运维管理oracle数据库一样，ASM做为一个管理ASM磁盘的实例，也是一个数据库，在正常的运维中，我们除了借助asmcmd字符交互界面外，查看基本的视图也是一个必不可少的方法，以上3张视图是本人认为使用热度最高的视图。 V$asm_diskgroup视图用户查看磁盘组的信息：比如磁盘组名、状态，磁盘组大小，使用率 版本参数等等。 V$asm_disk视图同样的，包含整个盘信息，包括盘属于哪个磁盘组，mount状态，盘大小，剩余大小属于哪个failgroup等。 V$asm_operation视图用户我们在日常增删磁盘操作的时候如何查看是否已经做完平衡操作，以及整个reblance的完成进度。RAC日常运维场景，该场景取自个人日常经验，每个场景基本一年总要接触N次比如增删节点，比如更换磁盘 比如备份盘头等等，熟练的掌握以上场景可以更好的帮助我们理解并维护RAC。这里我们开始分享几个简单的RAC案例： 1.如何准确判断10g及11g集群是否自启动 2. 10g 及11g CSS资源问题导致的迁移失败 3.一次曲折的addNode过程 4.心跳网络导致集群addNode失败 5.单机转RAC后应用无法连接数据库案例一：在10g及11g RAC中，集群往往随操作系统启动而自启动，这对我们进行一些日常性的操作系统维护产生极大的不便，在大型运营商及金融客户，我一般建议客户关闭该自启动特性，但是有时候我们并不清楚是否有关闭该特性，本案例并不算任何=性能故障，只算一个小技巧，给出10g及11g下RAC是否自启动的一个查看方式。案例二：对11g新忒性了解不够，客户采购了新服务器存储后想要体验11gRAC，而又不想升级数据库，由此产生了一个现在我们还是有很多客户在使用的一个架构：11g RAC 下运行10g数据库。 在新服务器上，我们将11g RAC搭建完毕，数据库软件也正常安装起来，磁盘组也正常创建，一切视乎都和我们预想的没有任何区别，但是当我们将数据文件从老的10g文件系统中，拷贝到11gASM磁盘组中时候，出现问题，拷贝无法成功，报错：ORA-29702:error occurred in Cluster Group Service operation 从报错看，似乎用11g RAC管理10g的RDBMS存在一定问题，似乎不能正常管理。案例三：addNode作为RAC中一个比较重要的操作，一般作为乙方单位，基本上每年都要碰到好多次，其实RAC的增删节点一直是我比较诟病的，复杂，麻烦，又慢。但是说来说去，又是一项不得不掌握的技能，本次故障就是一次在11g RAC环境中，某个节点主机失败后，重装主机后将节点重新加回的过程，简简单单的一个过程，因为连续碰到三个问题，又是在AIX环境下，竟然折腾了快4个小时。 addNode分两部分，第一部分即为addNode后集群将grid文件从好的节点往需要添加的节点拷贝，拷贝结束后运行root.sh脚本。 ·自检失败无法跳过，添加无法继续·添加过程中JAVA内存溢出·添加最后部分文件没有拷贝到损坏节点 下面我们来一次说明以上三个问题。自检失败，对于该报错，如果做过这种addNode操作的，而且采用的是/etc/hosts解析而非DNS解析的应该碰到过PRVF-5636 : The DNS response time for an unreachable node exceeded "15000" ms on following nodes: rac2,rac1 我们分析了该脚本：if["$IGNORE_PREADDNODE_CHECKS"="Y"-o!-f"$OHOME/cv/cvutl/check_nodeadd.pl" ] 可以看到，脚本中对自检过程进行了判断，我们可以手动跳过自检命令：export IGNORE_PREADDNODE_CHECKS=Y第二个小插曲发生在开始添加节点文件的时候，异常报错：Exception in thread "Thread-62" java.lang.OutOfMemoryError 虽然这个报错很简单也很明确，JAVA内存不足导致内存溢出进而进程异常，从addNode.sh脚本中我们可以发现，调用进程$OHOME/oui/bin/runInstaller命令，不过该命令为二进制，需要进一步解析，此时，我们同步在MOS文档上，参看到文档：1085893.1 发现定义JAVA内存大小的文件就在当前目录下的oraparam.ini文件的JRE_MEMORY_OPTIONS 默认为150M 我们临时调整到1G，后续添加正常。第三个报错相对简单，在报错后我们查看了报错日志：PRCF-2023 : The following contents are not transferred as they are non-readable. 显示以上文件无法拷贝，权限不足导致无法读取，我们检查了上述文件，均是一节点生成的一些集群LOG 对整个集群add过程并没有任何影响，我们忽略该报错，继续后正常。 上述案例其实也并非很复杂，只不过在金融客户里，这种操作一般都是掐着指头算着时间，往往没有给你很多的研究错误的时间，如何准确定位问题并在规定的时间内解决该问题才是最主要的。下面案例同样是一次节点添加过程，我们说了在addNode过程中，分成两部分，第一部分是往添加节点拷贝集群文件，第二部分是通过root.sh脚本将新节点加入到整个集群环境中。本次案例与上一个案例不同，这个案例问题发生在运行root.sh脚本中（该日志也是取自root.sh的后台日志脚本也就是我们刚才说的$ORACLE_HOME/cfgtoollogs/crsconfig/rootcrs_hostname.log位置下的脚本） 报错信息如下：node 1, lqwsjdb01, has a disk HB, but no network HB 很简单的一个错误信息，首先我们先定位问题，由于添加节点以前本来就是该集群中，只是因硬件故障所以重新删除添加，唯一的不同就是操作系统重装了，并且报错原因也很明确：存在磁盘心跳，但是在建立网络心跳的时候出错，没有网络心跳。 那么问题就简单了，我们定位问题出现在网络上，但是网络并没有做过任何改动，只是重装了操作系统。 首先我们互ping了两个节点的心跳，发现没有问题，这个时候问题就来了，似乎出现可卡顿，没有思路可循，我们重建检查了两个节点的网络配置文件。仔细检查两块网卡的信息我们发现，主机工程师在配置网络的时候可能是随手摘抄了一份文档，或者是压根就没有理解这个参数的意思，导致掩码两边不一致，也造成了oracle认为这两个网络在，不同的网段上面255.255.255.0证明在10.1.100.0网段而255.0.0.0在10.0.0.0网段，两者网段不一致，当然心跳网络就出问题，也就是为什么我们的css服务无法正常启动。 以上案例也告诉我们，虽然只是很简单的一个操作系统问题，但是如果你没有对操作系统命令由一定的熟悉，不知道网卡配置中的一部分参数，这个问题你可能并不能在第一时间发现。案例背景：客户的系统从单机改造成RAC模式，新系统上线后，业务无法正常连接，测试连接报错：$“scott/oracle@tbsrun，ERROR:
ORA-12543: TNS:destination host unreachable 由于测试的时候并没有发现这个问题，而且进一步发现同网段的业务都可以正常连接，无法正常接连的都是跨网段的业务系统。 首先同网段的业务系统既然都可以连接说明RAC本身是没有问题，最大的问题还是出在网络层面，但是发现从客户端发起各种ping都没有问题，而且tnsping返回也很快。至此问题似乎陷入一个僵局，你不能告诉网络工程师网络存在问题呀，因为你拿不出实际的依据来。 既然tnsping没有问题，说明客户端到生产的发包和回包应该都没有问题，那么具体是哪里出问题了呢，我们尝试通过sqlnet跟踪会话连接，尝试解析连接的整个过程来确定问题出在哪里。分析日志是相对比较痛苦的过程，冗长又不方便，在这里我只贴出部分简单而突出重点的部分，如果大家对这个案例不明白，可以去我的博客上看详细的trace分析文件。 我来说说明一下整个sqlnet跟踪的核心几个关键点： 开启sqlnet跟踪：1.跟踪信息读取，包括跟踪级别，基本的跟踪参数读取位置2.对连接串进行解析并确认3.开始创建连接，发起连接4.从客户端发送一定bytes的包，并确保发包成功5.开始从服务端的回包过程，发回一定字节的包6.以上为整个握手协议过程，到这里整个握手协议成功，我们平时测试的tnsping也就是到这一步7.如果是单机就开始派生连接8.如果是RAC的话开始将连接派发给VIP由VIP进行和客户端的整个握手协议，如果成功，则连接派生。 从我描述的整个过程结合之前我们的测试（tnsping可以，连接无法成功） 我们可以判断，问题应该是处在第8步，通过检查跟踪文件，果然，大家可以看整个跟踪文件与案例。虽然是一个连接问题，可能大伙觉得和RAC关系性不大呀，但是我放在这里主要是为了和大家说明很多人在从10g升级到11g的时候常常会和客户说，整个升级是完全透明的，业务没有改动的需求，其实不然，大家不能忽略了SCAN并不是真正用来进行连接，它只是进行一个派发，真正和客户端进行连接的还是VIP。在金融或者大型运行商中，对于网络安全限制是比较严格的，说开放什么端口就是什么端口，多不得一个，也不会少一个。因此要提前预估好各种需求。本次演讲就到这里了，后续的PPT及相关文档，我会提交给群主，相关的资料我也会上传到ITBUP论坛数据库管理板块下的ORACLE高可用子版块。
互动筛选Q1：应老师，rac卸载一般需要注意什么？如果没有安装的话可否暴力卸载？
A1：在11gRAC卸载中，如果是普通的卸载我们可以采用正常的RAC自带的deinstall功能： $ORACLE_HOME/deinstall/deinstall 。而在10g中，我们则更多的采用手动删除 。暴力卸载一般采用手工rm方式，只要将关键的文件系统rm掉，/etc/ohasd的进程启动文件删除，ocrvote盘正常dd操作，即可正常删除 。
Q2：11g的scan ip和vip的区别是啥？我们用scan ip，好像没发挥作用 。A2：使用scan vip的目的是减少因为添加删除节点，所带来的client配置操作，比如应用不需要调整等等 对于节点的增删也有一定的帮助，方便配置 。
Q3：应老师，脑裂一般怎样判断？ A3：脑裂我们需要获取到两个节点的OCSSd进程对应的仲裁信息。通过分析ocssd.log我们可以进一步获取脑裂时候的仲裁过程
Q4：老师，那11g大家都用scan了吗 ？A4：应该说采用11g的基本上会改造成scan使用，有些重要的系统可能为了方便，而不用SCAN 依旧采用vip的模式 。
Q5：应老师，仲裁盘替换需要注意什么？ A5：仲裁盘的替换并没有什么特别需要注意的地方，如果只是替换磁盘组中的磁盘，那么通过增加磁盘，删除磁盘的操作，oracle会自动进行reblance 。当然，增加删除盘最重要的是要考虑磁盘组的权限。
Q6：应老师，11g rac心跳网络需要配置双网卡绑定么？ A6：目前我们很多采用双网卡bond技术或者AIX的etherchannel 当然，目前我认为在11.2.0.4上HAIP也已经非常成熟。
Q7：应老师， 我们系统上了rac以后，运行一段时会出现单节点的cpu利用高，另一个节点很低的现象，您遇到过吗，我们是alx7.1,oracle11.0.2.4 A7：曾经有碰到过因为某条SQL的产生多个执行计划，导致两个节点的执行计划不一致，从而导致某个节点CPU大量开销，但是这只是有可能，具体的原因还是要具体分析，看CPU是被主机开销还是oracle进程开销，如果是oracle进程开销，可以分析一下AWR报告 。
【微学堂】第三期 预告：
主讲主题：开源安全运维平台OSSIM 企业实践
主讲老师：李晨光
讲师简介：李晨光，毕业于中国科学院研究生院，目前就职于世界500强企业，资深网络架构师、51CTO学院讲师、IBM精英讲师、UNIX/Linux系统安全专家，现任中国计算机学会（CCF）高级会员；在国内《计算机安全》、《程序员》、《计算机世界》、《网络运维与管理》、《黑客防线》等专业杂志发表论文六十余篇。曾独著畅销书《Linux企业应用案例精解》、《Linux企业应用案例精解第2版》，《Unix/Linux网络日志分析与流量监控》等经典学习教程，均被中科院图书馆、国内重点高校图书馆和国立台湾大学图书馆等200多家图书馆收藏。《Unix/Linux网络日志分析与流量监控》一书，于2015年获最受读者喜爱的本版类图书奖。
论坛ID:cgweb (ChinaUnix元老)
2016年1月13日晚八点准时开讲，感兴趣的小伙伴，请加扫下面二维码进群：
页:
[1]