复杂环境下Oracle版本升级中常遇问题及解决方案

金融行业IT系统建设起步较早，随着这些年系统规模不断增大，大量早期系统都面临数据库平台升级的挑战。近年来，Oracle数据库版本和架构的升级变化速度明显加快，往往使得本应非常简单的软件版本升级，转变成整个系统平台架构的完全变化。很多IT管理人员对这种架构上的变化缺乏必要的心理准备和风险控制预案，工程准备工作不足，导致数据库升级过程中出现重大事故，或是新数据库平台运行的稳定性和性能远远低于项目预期。

Oracle CRS带来的可靠性变化

传统Oracle数据库仅包括一系列运行在主机高可靠平台之上的数据库进程，用户现有作业流程也基本基于这一体系，系统管理员负责底层平台的可用性，数据库管理员负责完成DB进程管理。在新的版本中，Oracle引入了自有的高可用集群管理体系——CRS，这一体系的设计初衷是为了替换传统的主机集群管理软件;但在实际应用中，由于CRS自身缺乏网卡链路冗余的管理手段，因此又不得不利用主机群集软件功能来进行网卡链路冗余控制，但IT管理人员往往忽视了两套集群软件协同工作对系统的风险。

传统架构上不允许两套群集软件共同管理同一套系统，这是由于群集软件工作在系统核心层，为了保障群集一致性，都具备在意外情况下关闭(Panic)主机来规避风险的技术特征，两套互不协调的集群软件一起工作会造成术语为“彼此同归于尽”的现象，从而导致系统变得异常不稳定。要规避这种风险，需要群集软件能够彼此相互协调或进行一定程度的集成，当某个集群软件需要Panic主机时，能够及时被另一个感知，并采取一致性行动。

Oracle ASM带来的可靠性变化

传统的Oracle数据库一般使用主机OS系统提供的逻辑卷作为其存储设备，由系统管理员负责存储管理。在新的版本中，Oracle废止沿用这一方式，转而引入Oracle自有的存储管理软件——ASM。用户必须在使用ASM和使用传统文件系统这两种方式中选择一种来进行部署，不管选择哪一种方式，IT管理者都面临架构上的变化。一般而言，采用文件系统方式更接近原有架构，而采用ASM管理方式对架构的变化相对比较大，由于ASM自身为Oracle数据库的一个进程，因此管理者必须意识到数据库进程已经和数据可靠性紧密耦合在一起，在数据可靠性方面，原有的操作流程必须进行相应的变更，另外，由于ASM实现原理和传统逻辑卷有较大区别，原有的存储分配方式和可靠性设计必须进行相应的变化。此外，管理者必须了解并接受ASM的一些技术限制，并针对这些限制在架构上进行一定程度的冗余设计抵御系统稳定性风险。

Oracle ASM带来的性能变化

在客户的Oracle现有环境中，I/O性能调优和故障处理一般属于系统管理员的职责范畴，因为这涉及大量OS、存储阵列、SAN交换网络方面的知识。而在Oracle新的版本中，如果选择ASM进行存储管理，那么IT管理人员应该意识到以下两点：第一，以往的最佳性能实践和磁盘阵列配置已经无法适用，如果原有数据库对性能特别敏感，那么必须考虑进行全库数据迁移的准备，这是因为ASM的条带大小和磁盘阵列的条带大小基准不匹配，这种不匹配会造成两个结果，即对磁盘阵列cache使用消耗过大而影响pre-fetch效率，以及由于多重条带跨界造成读写性能下降;第二，数据库管理员需要具备完整的OS和阵列的性能调优知识，必须同时具备DBA和系统管理员的双重能力，如果该条件难以满足，那么系统管理员必须进行相关的Oracle DBA课程培训。

如果企业IT组织形式和人员能力在项目完成周期内无法满足上述条件，那么最佳的技术选择应该是谨慎对待，通过采用文件系统承载的方式最大限度维持原有架构。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友