【深度战斗小分队】紧急出动Oracle11g Rac的挑战

去年中旬，某客户提出需要在服务器上安装Oracle11g Rac。我们的服务器操作系统在之前进行过Oracle11gRAC的适配，没有出现问题，也有安装RAC的技术文档。虽然客户自己的技术工程师是Oracle的OCM出身，但由于客户应用的一些软件更改了操作系统的默认软件包和环境变量，导致Oracle 11g Rac安装过程会和这些包产生冲突，仅按照文档操作无法完成安装，因此紧急要求我们提供技术支持。

为了尽快满足用户上线要求，部门决定派工程师去客户现场进行适配。截止至7月末，成功完成了客户需求，我有幸参与了该项目实施的全过程，现在在这里给大家分享一下其中的历程以及成果。

说到Oracle Rac的安装，首先需要解释一下Rac的工作原理：在一个应用环境当中，所有的服务器使用和管理同一个数据库，目的是为了分散每一台服务器的工作量，硬件上至少需要两台以上的服务器，而且还需 要一个共享存储设备。同时还需要两类软件，一个是集群软件，另外一个就是Oracle数据库中的RAC组件。同时所有服务器上的OS都应该是同一类OS, 根据负载均衡的配置策略，当一个客户端发送请求到某一台服务的listener后，这台服务器根据我们的负载均衡策略，会把请求发送给本机的RAC组件处 理也可能会发送给另外一台服务器的RAC组件处理，处理完请求后，RAC会通过集群软件来访问我们的共享存储设备。配置完Rac之后可以使数据库达到的“高可用，易伸缩，低成本，高吞吐等”目的，同时，基于两台同构计算机的相互监控，可以达到负载均衡的目的。

为了完成技术支持，首先，需要制定该项目的执行方案：
第一、与客户方面进行沟通，了解客户需求，询问需要安装的Oracle版本号，远程存储的类型，已经安装的软件和版本；派遣工程师去现场查看服务器操作环境，准备回公司复现操作环境。
第二、在公司复现客户方面的操作环境，测试安装遇到的问题，工程部和研发部的兄弟共同探讨解决办法。
第三、测试成功后，进行现场实施。

项目开始实施后，的确是出现了新的技术难点；粗略的概括为以下几点：

一、软件的安装环境；二、Oracle的安装包；三、客户预装的软件影响安装。

在部署安装环境的时候，由于客户使用了第三方软件，为了支持这些软件的运行，导致很多软件包不是操作系统的默认版本，而且该软件版本高于Oracle11gRac识别的最高软件版本；我们只能根据客户的操作系统环境进行软件包的降级或者工作。

从软件源来说：Oracle官方为了其商业用途，发布的版本都是源码包或者使针对特定RHEL系列的操作系统发布的rpm包，这就使得我们需要更改源码包进行安装，工作量不小。

 而Oracle的源码包默认的安装路径以及调用的环境变量都是根据Oracle的OEL操作系统来设计的，相比Oracle服务器OEL系统而言，不同操作系统上很多配置文件以及环境变量的存放位置都不一样，会产生写入错误或调用错误。

发现了所有问题之后，就要开始思考解决办法，安装Oracle的OEL操作系统，在操作系统上运行Oracle的安装程序，查看安装过程中的需要的依赖包，以及调用环境变量、写入配置文件等信息，研发的同事们各司其职，只用了两天的时间就成功的完全分解了OracleRac的源码安装过程。

分解完成后，首先从软件包入手，根据Oracle安装时需要的软件包版本，查看客户方面的操作系统中安装的软件版本，对比差异，找出有差异的包，使用合适版本的系统包进行替换。

依赖包调整结束之后，就开始了OracleRac安装的重头戏-更改配置文件，配置文件大致分为两部分，用户环境变量的配置文件，系统配置文件。Oracle服务器这方面提供的公开资料有限，需要进行单步跟踪对比两边差异，进行修改。

由于需要赶上用户的时间进度，参与这个过程的几位兄弟废寝忘食的工作，仿佛已经没有了时间的概念。基本都是两三天没有回家，就是为了早日完工，不把时间扔到路上。加班的这段时间里，大家都是竭尽全力的工作，困了就冲杯咖啡继续干，实在撑不住了就躺在沙发上睡一会儿，睡前还不忘和其他同事说一声：有问题马上叫我！大家还没回应，轻微的鼾声就已经响起了。

大家的努力是有回报的，从最开始的不能正常安装，到安装读条到达100%的时候，所有人有松了一口气，测试没有问题之后，安排进行现场实施，问题完美解决。

在适配过程中，深度的研发团队以及工程团队展现出了雄厚的技术实力-强大分析能力，对系统各层面软件和配置的熟悉；展现出了勇攀高峰，不畏险阻的研究精神，这就是深度的精神！

---