Ask Maclean

Oracle Acs资深顾问罗敏 老罗技术核心感悟：话说升级

作者为: 

SHOUG成员 – ORACLE ACS高级顾问罗敏

话说升级

长期以来，Oracle数据库系统升级是让IT系统决策者和管理者陷入两难境地的重要话题。一方面，IT系统高速发展所提供的大量新技术和新特性，对IT人员充满诱惑，也的确能解决现有IT系统中的大量问题。另一方面，面对各行业正在运行的、非常重要的生产系统，缺乏全面评估和验证的数据库系统升级操作，不仅可能会导致业务中断时间过长，更严重的是可能导致应用软件的不稳定性，甚至性能衰减。因此，犹豫和彷徨之中，IT系统决策者们一次次错失了升级的良好契机，所谓“一步赶不上，步步赶不上”。日积月累之下，不仅数据库技术老化，而且也妨碍了硬件、网络、中间件等其它层次新产品和新技术的运用，最终导致现有IT系统难堪重负。更有甚者，索性推翻原有IT系统，另起炉灶。这不仅导致大量重复建设，更使得现有系统的软硬件资源和数据资源难以继承，即导致整个IT系统的投入产出比(ROI)的下降。

关于Oracle数据库升级，业界到底有多少顾虑？为什么要升级？升级项目应该包括哪些实施内容？升级技术方案到底有哪些？如何防范升级之后应用软件性能不衰减？升级项目如何组织实施？如何防范风险？本章试图围绕这些话题一一道来，希望给大家在计划和组织升级项目实施时，起到抛砖引玉的作用。

关于数据库升级的疑虑

关于升级的矛盾和纠结

关于升级，IT行业不同层面和角色人员到底有哪些纠结、矛盾和疑虑？以下这张图大概能表白大家的很多共同心声：

upgrade1

 

上述“为什么要升级？”和“升级能带来什么益处？”，其实更多地是有关升级的必要性问题。而“升级如何保证停机时间”、“万一升级失败，怎么办？”、“新版本对应用是否兼容”、“升级后是否会导致性能下降”等类问题，则是有关升级的可行性问题了。最后，“如何使用新特性？”、“需要对系统运维工作进行哪些调整？”等问题，就不仅仅是将升级看成是一种被动而为的事情，特别是为了满足Oracle产品服务期限的需求，也不是一种新瓶装旧酒的保守思维方式，而是以更积极的心态，主动接受和拥抱新平台、新技术，将升级看成是一次升华的过程了。

本章和本书更多章节内容，都是在试图解答大家的这些共同的疑虑，从而帮助大家面对升级工作，树立起既积极乐观、又严谨缜密的思维模式和工作方法。

 

关于升级两种绝对观点

在多年与国内多个行业的众多客户探讨数据库升级时，我们经常听到如下两类截然相反的观点：

  • “升级是很简单的事情”

此观点更具体的叙述是：“升级哪有你们Oracle公司说的那么复杂，不就是建个11g新库，然后把9i、10g数据倒一遍吗？你们Oracle就想忽悠我们买你们更多服务吧？”

以本人经验，持这类观点的用户也是有所根据的：通常他们的系统数据量可能不大，例如最多只有几十GB。更重要的是，这类系统高可用性可能并不高，停几个小时、甚至停个周末进行升级都无所谓，几十GB数据慢慢倒几天呗。还有，这类系统的应用软件也比较简单，基本采用最基础、最经典的SQL语句，也几乎不可能在新平台运行时出现应用不兼容、性能衰减的问题。

不过，尽管这类客户的数据库升级风险不是很大，但麻雀虽小、五脏具全，同样也应考虑作为一个升级项目的方方面面的工作，例如升级技术方案的确定、性能稳定性保障、11g新特性运用、数据库是否需要整合等工作内容。

  • “升级太复杂了，风险太大了”

持这类观点的人当然是银行、电信、政府、制造等关键行业的客户了。这些行业的数据库系统不仅数据量动辄达到TB、甚至几十TB以上，而且几乎全部是7*24小时的关键业务系统。为了升级这种多年难遇的事情，也最多向主管部门申请数个小时的停机时间窗口，如何保证在这么短的时间窗口内，完成这么浩大的升级工作？

再则，这类关键系统的应用通常都非常复杂，不仅表、索引、分区、存储过程、函数等数据对象经常达到万个以上，而且国内应用开发高手们，经常写出数百行的单个SQL语句，这些SQL语句在新平台的兼容性，特别是性能稳定性如何保证？的确是困扰各层面人士的难题。

于是，就出现了上述犹豫和彷徨之中，一次次错失了升级的良好契机，所谓“一步赶不上，步步赶不上”的局面。

数年前，某电信公司将核心营业系统的Siebel应用软件进行升级，同时将数据库也升级到11g R2版本。尽管专门组织了由客户、集成商、Oracle原厂商等组成的团队，更进行了长时间的精心准备和测试，但依然在正式升级之后，出现了数据库宕机，并长时间停止对外服务的重大故障，甚至被媒体曝光。究其原因是多方面的，例如Oracle 11g进程内存消耗过大问题；测试期间模拟并发数不够，而投产之后更大并发数导致内存耗尽等问题。此次严重故障也让客户各层面人士，特别是高层承受了巨大压力，甚至导致客户得出了这样的结论：“以后我们再不为你们Oracle版本单独升级了，除非我们在你们新平台重新建设一套新系统。”

其实，深究其原因，还是在升级项目组织、工作内容、工作流程方面等方面出现了重大偏差，如果我们好好总结经验教训，还是完全可以借鉴并避免这些问题发生的。

 

关于升级的正确观点

关于升级的正确观点是什么呢？总体而言应该用“战略上藐视，战术上重视”来描述。首先以事实为依据，在笔者所在的Oracle高级服务团队（ACS）自从2007年开始在全国提供全面、系统的数据库升级服务以来，我们团队在国内各行业的数百个系统实施了升级到10g和11g的项目，尽管经历了大大小小的各种坎坷，但没有一个系统没有升级成功！因此，对于升级，我们完全可以持“战略上藐视”的态度。

但是，在我们经历的升级项目中，也的确出现过上述电信公司尽管没有回退,但充满坎坷的项目，更经历过第一周升级不成功而不得不回退，在及时总结经验教训之后，第二周成功升级的典型案例，这也恰恰说明升级工作的复杂性和风险性，也就是说“战术上重视”的重要性。

更具体而言，针对数据库升级工作，我们应持如下的观点和相应的工作方法：

  • Oracle数据库系统升级是一项机遇和风险并存的系统工程。
  • 对现有系统的全面了解和评估，升级需求的分析，合理的升级技术方案设计是升级项目的基础。
  • 性能问题是升级过程中需要特别关注的问题。
  • 科学的升级方法论指导和项目有计划的实施是升级的重要保障。

下面章节，我们就将围绕这些观点，以某银行现状和升级需求为背景，展开更进一步的讨论。

 

为什么要升级？

为什么要升级？其实主要原因只有两个：首先就是Oracle产品支持周期问题，其次就是充分运用新版本的新技术和新特性，有效解决现有版本无法解决的一些问题。有关11g新特性话题，我们已经在本书前面若干章节进行了讲述。本节只叙述Oracle产品支持周期问题。

Oracle产品均有自己的生命周期，下图就是Oracle9i、10g、11g数据库产品和服务的生命周期政策：

 

upgrade2

 

其中:

  • Permier Support（PS）表示Oracle标准支持服务期
  • Extended Support（ES）表示Oracle延长支持服务期，Extended Support需在标准服务费的基础上增加额外的延长支持服务费用，且要求客户的数据库需要升级到当前版本的最后一个补丁集，如9i R2的2.0.8，10g R2的10.2.0.5等。
  • Sustaining Support（SS）表示Oracle扩展支持服务期，相比Extended Support，客户需要支付更昂贵的服务费用，而得到的服务反而会更少。

下图就是Oracle官方提供的PS、ES、SS各类服务的详细情况：

 

upgrade3

 

可见，只有在PS情况下，Oracle公司提供的服务才是最全面的，而当产品处于ES和SS阶段时，得到的服务不仅越来越少，而且投入还会越来越多。

例如Oracle 10g R2最后一个补丁集(Patchset) 为10.2.0.5，在2010年7月就停止了PS服务，在此之后Oracle公司既不会为该版本推出新的功能，也不会为Oracle 10g R2提供任何补丁了。如果客户数据库系统发生了一个Bug，而这个Bug已经有现成补丁，客户在Oracle服务部门指导下，可直接采用该补丁。如果是新发现的Bug，除非客户花更多的服务费用采购了ES和SS服务，Oracle才会专门开发定制的补丁。

相比之下， Oracle目前主流的11g R2版本将可以获得Oracle公司从产品研发到全球支持服务部门的全面技术支持。Oracle在2014年7月之前将一直提供对11g第二版的PS支持，而ES支持则可以持续到2018年7月。

Oracle这种服务策略霸道吗？上述服务策略是霸王条款吗？作为Oracle公司人员，本人并不这么看待。Oracle制定这种服务策略，如同所有IT公司一样，的确是在鼓励客户与时具进，享受IT技术最新发展成果。再则，我们从商务层面也不难理解这种服务策略，Oracle公司毕竟要将最主要的研发技术力量放在最新的产品设计和开发之中，如果要兼顾老版本的技术支持，必将投入更多的技术资源，向客户收取额外服务费用也是可以理解的。

总之，为得到Oracle最强有力的技术支持，享受IT技术最新发展成果，也是为了提高客户在服务方面的投入产出比，Oracle公司还是强烈推荐客户能积极、稳妥地实施数据库升级操作，尽量采用Oracle数据库最新版本。

 

Oracle升级方法论（GSDK）介绍

GSDK概述

Oracle公司在总结历年为全球各行业广大客户实施数据库升级项目过程中，提炼出了一套结构化实施方法：Upgrade Service Global Service Delivery Kit (GSDK)。GSDK方法论详细定义了用于实施数据库升级的所不可缺少的步骤和任务。GSDK是一组预定义好的、在整个数据库升级项目中起指导作用的、可用多种方法管理的实施步骤。GSDK可以帮助我们解决诸如如何正确评估现有现状、如何制定升级计划、如何组织升级测试、如何具体组织实施升级、如何制定各种回退计划、如何防范各种可能存在的风险、如何合理使用新版本功能、如何解决应用软件兼容性、如何解决与其它系统软件平台兼容性等比较棘手的问题。

以下是GSDK的示意图：

 

upgrade4

 

即根据GSDK方法论，升级项目将分为计划、转换、优化等不同阶段，并在每个阶段完成相应的工作内容。

升级项目涉及的主要内容

根据ACS总结多年运用GSDK实施升级项目的经验，升级项目通常应包括如下四大类主要内容：

upgrade5

 

  • 数据库升级技术方案

如何根据现有系统运行状况，特别针对升级需求进行深入分析，合理运用Oracle各种相关技术，设计合理的升级技术方案，并制定缜密的实施计划，是升级项目最核心的工作内容。

本章下面就是针对某客户系统现状和升级需求分析，初步制定的若干种升级技术方案。详细的技术方案限于篇幅，就不在本书一一展开了。

  • 应用性能管理和优化

根据Oracle公司的总结，数据库系统升级的大量实践表明：90%问题并不是升级技术方案本身，而是升级之后的应用软件稳定性，特别是性能问题。

如何在11g升级过程中，制定合理的应用性能管理和优化方案，并加以有效实施，同时有效运用11g性能管理和优化相关新技术，将是升级项目的重要工作内容。下面还将专题讨论性能问题。

  • 11g新特性运用

Oracle 11g R1和11g R2版本推出了大量新特性和新技术，为设计和开发更高质量的IT系统提供了良好的技术基础。但是，凡事都有利弊，在ACS升级11g和实施11g的项目中，几次出现问题，均与11g若干新特性相关。例如：

  • 在某移动公司升级到1.0.7项目中，出现严重的资源消耗过高的问题，则与11g R2的auto space advisor特性出现Bug相关。
  • 在某银行升级到2.0.3项目中，部分语句因为11g R2的SQL tuning advisor特性产生了不良SQL Profile，从而导致执行计划变异，最终导致性能下降，资源消耗过大。

可见，如何制定合理的11g新特性运用策略，有效规避新特性带来的风险，将是升级项目需要充分考虑的重要方面。

  • 架构整合服务

多年来，国内外大多数行业在IT系统建设中，由于各种技术、业务等方面原因，建设了大量相对独立的，类似于如下竖井式的IT系统：

upgrade6

即大多数IT系统均为专有的硬件和软件，每套系统运行单一应用。这种架构之下，系统之间的软、硬件资源通常没有共享，导致每套系统均为最高峰值而配置，不仅投入成本高，而且难于扩展，运行维护成本也居高不下。

为有效解决现有IT系统的上述问题，Oracle公司以云计算为理念，提供了如下的云计算基础架构环境：

upgrade7

 

即在存储、数据库和应用服务器等不同层面均提供了资源共享池技术基础架构，从而打破了现有IT系统之间相对隔离的状态，不仅具有了资源共享能力，而且具有快速供应能力、灵活的伸缩性和集中监控管理等。

Oracle在11g R2中更是提供了若干针对性的技术，例如：RAC中Service技术的增强、基于策略的RAC管理技术（Policy-managed Oracle RAC）、网格即插即用技术(Grid Plug and Play)、资源隔离（Instance Caging）技术等。

建议客户利用11g升级项目，对现有系统进行一次全面调研，并有针对性地合理制定架构整合方案，运用11g相关技术，将若干系统进行有效整合，从而全面提高系统的资源利用率、降低 IT系统的建设和运行维护成本。

 

现状及升级改造需求分析

以下我们对某银行数据库现状及升级改造需求进行分析。

系统现状

通过与该银行相关人员的沟通，以及参考 Oracle ACS历年来的相关服务实施报告，我们初步了解该银行Oracle数据库状况如下：

  • 主要硬件平台为IBM AIX和HP 平台
  • 大部分为RAC系统，数据库版本为2.0.4。
  • 存储设备有EMC和HDC两种，采用裸设备技术。
  • 备份策略主要采用RMAN + Veritas。
  • 大部分没有采用容灾系统。个别系统采用了Data Guard，较重要的系统采用了磁盘镜像技术。

升级需求分析

通过与该银行升级项目组的初步交流，客户对Oracle数据库升级总体需求如下：

  • Oracle数据库升级目标版本为11g R2最新版本。例如：2.0.3。
  • AIX平台将采用到1。HP平台将采用11.31。
  • Oracle数据库存储技术将由现在的裸设备迁移到ASM技术。
  • 大部分系统将迁移到新采购的存储和主机上，但也会有少量原地升级的系统。
  • 跨平台迁移的系统不多，但部分HP PA平台需要迁移到HP IA平台。
  • 全面升级之后，应保持AIX、HP UX、Oracle、WAS、CICS等软件版本之间的兼容性，对应用程序的影响应降至最少。
  • Oracle数据库升级时间窗口应尽可能短。每套系统的具体时间窗口,将根据系统重要性、环境等情况而定。
  • 升级过程应具有良好的回退方案，以防万一升级失败，能回退到旧系统，最大限度降低对外服务的影响。回退时间窗口，同样将根据具体情况而定。

 升级和迁移技术方案

升级方案1：数据逻辑迁移

  • 方案要点

该方案的主要思路是部署新生产环境，包括安装11g R2软件并创建基于ASM的数据库，然后通过Data Pump或Exp/Imp技术，将现有10g R2数据库数据，加载到11g R2数据库之中。

方案示意图如下：

 

upgrade8

 

  • 在新生产系统服务器上安装11g R2软件，并创建基于ASM的数据库
  • 通过Data Pump或Exp/Imp技术，将现有10g R2数据库数据，加载到11g R2数据库之中。
  • 方案优点
  • 跨平台、跨版本
  • 相比后续技术方案，该方案技术难度低。
  • 通过数据导出/导入，可有效进行数据库碎片整理，降低数据库容量，提高新库的访问效率。
  • 如果升级失败，可直接启用原有2.0.4 + 裸设备环境，回退速度快，难度和风险不大。
  • 方案缺点
  • 在数据逻辑迁移期间，虽然现有生产系统没有停机，但为了保证数据逻辑完整性和一致性，现有数据库将停止对外服务。时间长短，取决于数据库容量。针对TB级数据库，预计很难满足升级时间窗口需求。
  • 如果在应用层面设计逐次导出/导入方案，复杂度和实施难度较高。

升级方案2：原地升级

  • 方案要点

该方案的主要思路是在现有生产环境部署新的存储设备，并创建10g ASM磁盘组，然后通过RMAN相关技术，实现裸设备到ASM的复制和切换，最后再升级为11g R2数据库。

方案示意图如下：

 

upgrade9

 

  • 在现有数据库服务器上安装11g R2软件
  • 增加与现有存储资源相当的新存储资源，并在现有10g R2环境下创建ASM磁盘组。
  • 通过RMAN的如下典型命令，完成裸设备到10g R2 ASM的整库迁移：
CONNECT TARGET
STARTUP NOMOUNT;
RESTORE CONTROLFILE FROM 'filename_of_old_control_file';
ALTER DATABASE MOUNT;
BACKUP AS COPY DATABASE FORMAT '+DATA';
SWITCH DATABASE TO COPY;
RECOVER DATABASE;

也可在表空间级进行裸设备ASM的迁移，详细命令略。

同样地，也可在表级或分区表级进行裸设备ASM的迁移，即先创建基于ASM磁盘组的表空间，再通过“Alter table <表名> move tablespace <基于ASM磁盘组的表空间>”或“Alter table <表名> partition <分区名> move tablespace <基于ASM磁盘组的表空间>”方式，逐表进行迁移。

 

  • 在11g R2环境下，对2.0.4的ASM数据库启动升级脚本，完成最终升级操作。
  • 原有2.0.4的裸设备资源可释放。

另外，也可采取如下类似方案：

  • 先在现有2.0.4环境启动升级脚本，升级到11.2.0.3。
  • 再通过RMAN操作，完成裸设备到ASM的整库迁移。
  • 方案优点
  • 只需要增加磁盘资源，不需要新增小机资源。
  • 相比后续技术方案，该方案技术难度略低。
  • 如果升级失败，可直接启用原有2.0.4 + 裸设备环境，回退速度快，难度和风险不大。

 

 

  • 方案缺点
  • 生产系统需要在停机情况下升级操作系统软件、数据库软件、中间件和其他系统软件，操作时间和影响对外服务时间长。例如整库迁移到ASM，可能耗费数小时，很难满足停机时间窗口需求。
  • 根据该银行的运行维护规定，提前连接磁盘属于生产变更，可能会影响生产系统运行。

 

升级方案3：表空间传输

  • 方案要点

该方案使用表空间传输（TTS）技术，将10.2.0.4的表空间直接挂载到11g数据库上，实现数据库的升级。TTS不仅支持跨数据库版本，10g后还支持跨平台迁移，是一种高效的实现数据迁移的方案。

方案示意图如下：

upgrade10

 

该方案总体步骤如下:

  • 在新生产系统安装2.0.3软件和数据库
  • 在源库和目标库创建directory，用于存放dump文件
  • 将源库的应用表空间设置成read only方式
  • 使用expdp导出源库应用表空间的metadata信息（不包含实际的数据），通常只有几兆的数据
  • 将metadata和应用表空间对应的datafile传输或远程复制到新的主机
  • 使用impdp将表空间metadata导入11g数据库，把datafile直接挂载到11g数据库。
  • 把源库和目标库的表空间改成read write方式

该方案将使用裸设备到ASM文件的转换技术。

  • 方案优点
  • 方案相对简单，步骤较少。
  • 需要增加磁盘资源，不需要新增小机资源。
  • 相比后续技术方案，该方案技术难度略低。
  • 如果升级失败，可直接启用原有2.0.4 + 裸设备环境，回退速度快，难度和风险不大。
  • 方案缺点
  • 在测试和验证过程需要将生产系统表空间改成read only，对生产系统的使用有影响。
  • 网络文件传输的速率决定了整体升级的时间，如果速度很慢，升级时间将大大增加，需要在测试环境搭建好以后，先测试网络文件传输效率。
  • 裸设备到ASM文件的转换技术较为复杂。

升级方案4：Data Guard方案

  • 方案要点

该方案需要先部署新生产环境，并通过10g Data Guard在新生产环境部署现有生产系统的容灾数据库。在正式升级过程中，将容灾库切换为生产库，再通过运行升级脚本，将10g R2数据库升级到11g R2数据库。

方案示意图如下：

 

upgrade11

 

  • 首先需要部署不低于现有生产系统环境的新生产系统环境，包括主机和存储资源。
  • 在新生产环境服务器上安装2.0.4和11.2.0.3软件
  • 在不影响现有生产系统情况下，通过10g Data Guard技术在新生产环境服务部署现有生产环境的容灾数据库，并采用ASM技术。
  • 在正式升级时间窗口，通过Data Guard的Switch over操作，将新生产环境的容灾库切换为生产库。
  • 在新生产环境启动2.0.3系统，并mount 新生产库，启动升级脚本，完成最终升级操作。
  • 方案优点
  • 总体升级时间短

该方案在搭建Data Guard时，不需要生产系统停机。在正式升级时，Switch over操作为分钟级，而升级脚本的运行与数据库容量无关，而只与数据字典大小相关。根据Oracle实施经验，该方案总体升级时间窗口约2-3小时。

  • 回退窗口快捷

如果升级失败，可直接启用原有生产系统的10.2.0.4 + 裸设备环境，回退速度快，难度和风险不大。

  • 方案缺点
  • 需要额外新增小机资源
  • 相比第一种技术方案，该方案技术难度略高。

升级方案5：PPRC + Golden Gate方案

  • 方案要点

该方案综合运用PPRC磁盘镜像技术、GoldenGate等技术。首先通过PPRC创建中间库，然后通过Data Pump技术将数据加载到新生产系统，再通过GoldenGate实现现有生产库和新生产库的数据同步，并最终一次性进行割接。

该方案最大优点是几乎可以零停机方式，实现数据库的升级。方案示意图如下：

upgrade12

 

  • 该方案需要部署中间库环境，包括安装2.0.4软件。其存储设备与现有生产系统必须同等型号，但主机资源可低于现有生产系统，例如单机环境即可。
  • 该方案还需要部署不低于现有生产系统环境的新生产系统环境，包括主机和存储资源，并安装2.0.3软件和ASM数据库。
  • 通过磁盘镜像技术（PPRC）构造与生产系统相同的2.0.4中间库。
  • 在中间库进行Data Pump卸载之前，记录中间数据库的时间点（timestamp），或者SCN，或者Log file sequence
  • 将中间库数据进行Data Pump卸载（expdp）之后，再将数据通过Data Pump加载(impdp)到新生产环境的2.0.3之中。
  • 再通过GoldenGate技术，从现有生产库的指定时间点（timestamp），或者SCN，或者Log file sequence开始，将现有生产库数据同步到新生产环境的2.0.3之中。这样，现有生产库与新生产环境数据将逐渐保持一致。
  • 只需要GoldenGate将生产系统所有日志同步到目标库之后，即可进行正式割接。
  • 方案优点
  • 总体升级时间最短

该方案在通过PPRC搭建中间库，以及实施GoldenGate时，几乎不需要生产系统停机。因此，该方案总体升级时间最短，几乎可以做到零停机。

  • 回退窗口快捷

如果升级失败，可直接启用原有生产系统的10.2.0.4 + 裸设备环境，回退速度快，难度和风险不大。

  • 方案缺点
  • 需要额外新增中间库和新生产环境两套资源
  • 需要硬件厂商参与该方案的设计和实施
  • 相比前面几种技术方案，该方案技术难度最高

GoldenGate实施有若干技术限制，需要结合具体系统情况，充分加以论证。

 

升级方案6：RMAN + Golden Gate方案

  • 方案要点

该方案综合运用RMAN、GoldenGate等技术。该方案首先在新环境搭建10g ASM环境，然后通过RMAN将现有生产系统数据恢复至新环境，并记录下日志序列号。然后将新环境升级到11g，并通过GoldenGate技术保持数据同步，最终通过切换完成升级和迁移。

方案示意图如下：

 

upgrade13

 

  • 该方案需要部署新生产环境，包括分别安装2.0.4、 11.2.0.3软件，并部署ASM。
  • 首先，通过RMAN技术，将现有生产系统数据库恢复到新生产环境的2.0.4的ASM数据库中，同时记录下RMAN最新恢复的日志序列号。
  • 其次，在新生产环境通过手工运行升级脚本方式，将该库升级为2.0.3
  • 然后，在通过GoldenGate技术，从现有生产库的指定日志序列号开始，将现有生产库数据同步到新生产环境的2.0.3之中。这样，现有生产库与新生产环境数据将逐渐保持一致。
  • 只需要GoldenGate将生产系统所有日志同步到目标库之后，即可进行正式割接。
  • 方案优点
  • 总体升级时间最短

 

与方案5相似，该方案总体升级时间最短，几乎可以做到零停机。

  • 节省资源

相比方案5，可以不需要中间库的主机和存储资源。

  • 回退窗口快捷

如果升级失败，可直接启用原有生产系统的10.2.0.4 + 裸设备环境，回退速度快，难度和风险不大。

  • 方案缺点
  • 生产系统需要更多存储空间，保留RMAN恢复期间和11g升级期间的归档日志。
  • 相比方案5，由于采用了RMAN技术，因此不支持跨平台。
  • 相比前面几种技术方案，该方案技术难度也较高。
  • GoldenGate实施有若干技术限制，需要结合具体系统情况，充分加以论证。

方案总结和建议

以下是上述五种方案的对比和总结：

编号 方案 跨平台 升级时间 环境要求 技术复杂性 可回退性 应用关联性 适用场景
                 
1. 数据逻辑迁移 支持 数小时 一套额外存储和主机 较简单 良好 与应用相关 数据量不大，停机时间窗口较长的系统
2. 原地升级 N/A 2-3小时 一套额外存储 较简单 良好 与应用无关 数据量大，停机时间窗口在2-3小时左右的系统
3. 表空间传输 支持 数小时 一套额外存储和主机 较简单 良好 与应用相关 数据量不大，停机时间窗口较长的系统
4. Data Guard方案 不支持 2-3小时 一套额外存储和主机 复杂 良好 与应用无关 数据量大，停机时间窗口在2-3小时左右的系统
5. PPRC + Golden Gate方案 支持 几乎零停机 两套额外存储和主机 最复杂 良好 与应用无关 数据量大，停机时间窗口要求最短的系统
6. RMAN + Golden Gate方案 不支持 几乎零停机 主机需要更多存储资源 复杂 良好 与应用无关 数据量大，停机时间窗口要求最短的系统

根据上述综合分析，我们建议如下：

  • 如果数据量不大，或者停机时间窗口允许，可选择数据逻辑迁移、原地升级或表空间传输。
  • 否则，建议考虑Data Guard方案、PPRC + Golden Gate方案、RMAN + Golden Gate方案。
  • 如果跨平台，还不能选择Data Guard方案和RMAN + Golden Gate方案

 

19.6 升级中的性能优化和性能管理

性能问题需特别关注

作为Oracle中国公司专门从事数据库升级工作的ACS服务团队，我们对性能问题感同身受。例如在某移动公司的升级过程中，由于我们在设计阶段充分调研分析了系统现状和升级需求，精心设计了4套升级技术方案，并经过充分演练，基本保证了升级操作本身的顺利完成。但在升级投产之后，性能问题就开始显现，如执行计划更改、优化器更改、游标问题等导致的性能下降。深入分析，无外乎以下三类原因所导致：

  • 原有应用软件就存在性能问题，在新平台不仅不可能直接得到改进，而且显现得更加明显。
  • 原有应用运行在RBO模式，在10g/11g中被强制运行在CBO，而导致应用执行计划出现不良变异。
  • Oracle某些新特性方面存在Bug。例如Bind变量的Peeking功能。

上述问题其实都可以通过在测试阶段，加强应用软件的压力测试而得到有效解决。

如何降低升级过程中的性能风险

  • 项目组织和投入

首先，建议在升级过程中，关于性能问题可能带来的风险，能引起相关部门领导和技术负责人的重视，并在项目组织和投入方面能给予充分考虑。例如，在项目计划中能将应用软件兼容性测试和压力测试，作为单独的任务项，并安排相关资源和环境进行充分测试。特别是需要应用开发商进行资源投入和配合工作。

下面章节关于实施建议方面，给出了更详细的项目周期、项目组织、资源投入、职责等方面的详细建议。

  • 现有应用软件进行必要的优化

应用软件的优化是一项长期而艰巨的任务。由于时间和资源的关系，我们不可能在升级项目过程中解决所有性能问题，但我们建议在升级项目的应用软件测试过程中，将一些不涉及整体架构，或者不需要进行应用软件大幅度改造的问题，尽可能加以优化，避免在新平台重现这些问题，甚至引发其它问题。

  • 采用11g的性能优化管理新技术

为保证应用软件在升级前后的稳定性，建立合理采用如下的11g性能优化管理新技术：

  1. SQL Performance Analyzer

以下是SQL Performance Analyzer的流程图：

upgrade14

 
即首先在生产环境捕获所关注的SQL语句，并存储在SQL Tuning Set(STS)中；然后将STS传输到测试环境中；在变更之前的测试环境下，先运行STS，并记录性能基准指标；测试环境实施变更，例如数据库升级；再运行STS，并记录变更之后性能指标；最后SPA将产生相应的性能对比分析报告， 包括性能无变化报告、性能提高报告、性能衰减报告。SPA可结合SQL Tuning Set(STS)、SQL Tuning Advisor和SQL Plan Management等工具和技术，对存在性能衰减的SQL语句直接给出优化建议。

SPA目前可支持9i、10g到11g的升级。SPA技术可为升级过程中所特别需要关注的SQL语句性能管理，提供有效的分析和诊断手段。

  1. SQL Plan Management

SQL Plan Management（SPM）是Oracle 11g最新推出的保证SQL语句执行计划稳定性，以及性能整体稳定性的新技术。SPM通过自动维护SQL语句执行计划历史记录，并确保优化器每次选择代价最低的执行计划，来保证应用性能稳定性。

数据库升级、开发测试环境到生产环境的应用迁移等场景下，SPM具有良好的应用空间。例如，以下就是在数据库升级场景下，SPM的应用示意图：

upgrade15

 

 

即首先在现有生产环境，通过上述SPA工具的使用，捕获典型业务周期的SQL语句，形成STS包。然后将STS包传输到新的11g数据库之中，并将这些语句执行计划形成Baseline。

在新的11g环境运行时，Oracle可能形成新的执行计划，优化器自动进行比较：如果性能更好，则选用新执行计划，否则，继续沿用现有的从10g传输过来的Baseline执行计划。

这样，通俗地讲：通过SPA和SPM的综合使用，可保证11g环境下的相同语句可能运行性能更好，但不可能低于10g的运行效率，从而保证了运行性能不会出现衰减。

 

升级项目的实施和组织

针对该银行的大规模升级项目，建议成立专门的项目组来开展此次11g测试及升级服务方案设计工作，该项目组由XX银行、Oracle公司，以及其它方面专家共同组成。

upgrade16

 

 

上述人员的主要职责如下：

项目方 人员 职责
     
XX银行银行 项目负责人 l 负责整个项目的组织、协调工作

l 负责项目总体方案的评审

l 负责项目确认和验收
运行维护人员

 

 l 负责协调系统硬件的准备，包括测试系统和生产系统的主机系统、网络设备和存储设备等，并保证其正常运行

l 负责及时提供详尽的系统需求，以及相关的资料

l 参与RAC实施方案

l 参与11g新特性研究工作

l 参与升级方案预研工作

l 协调应用开发等部门关系
应用开发人员 l 负责应用系统信息提供

l 参与RAC实施方案

l 参与11g新特性研究工作

l 参与升级方案预研工作
测试人员 l 负责测试环境的准备

l 参与RAC实施方案

l 参与11g新特性研究工作

l 参与升级方案预研工作
Oracle公司 技术架构师 l 负责各总体方案设计

l 参与Oracle环境安装和部署

l 参与测试工作

l 参与各方案的实施

l 负责11g技术知识转移
实施顾问 l 负责各总体技术方案设计

l 负责各详细技术方案设计

l 负责Oracle环境安装和部署

l 负责各技术方案测试和实施

l 参与11g技术知识转移
Oracle全球客户7*24二线服务支持及产品研发中心 l 对一线现场专家提供二线支持及后备

l 以800免费咨询电话及互联网的方式提供产品支持服务

l 提供补丁援助

说明如下：

  • 上述组织结构没有包括Oracle公司销售经理、服务实施经理（SDM）等人员，其职责应包括与各方资源的协调、Oracle团队的资源管理和协调、参与项目总体方案的评审、项目确认和验收等方面工作。
  • 由于此次11g测试及升级方案研究工作，涉及硬件服务器、操作系统、数据库、中间件等各个层面的升级，因此上述项目组织结构还应该包括中国建设银行负责上述其它层面的技术人员，并在必要时得到上述其它产品的原厂商技术支持。

 

升级风险评估控制

在这里，我们分析一下升级本身可能遇到的风险及相应的规避方法。从风险定义来讲，是由于不确定因素导致的损失。对于数据库升级项目，如果我们能够从技术和实施两方面充分考虑到各种可能的不确定因素，采取有针对性的规避方法，就可以把风险降到可控范围或完全消除风险。

关于硬件、网络和软件的风险

序号 可能遇到的风险 风险等级 可能造成的后果 风险规避方法
         
1 客户可能无法及时提供用于系统实施的测试环境资源 高 无法进行系统实施的测试工作，影响项目实施进度。 尽早准备测试环境的硬件资源，搭建完整的测试环境，用于系统实施相关的各项测试工作。

升级中的风险及规避方法

序号 可能遇到的风险 风险等级 可能造成的后果 风险规避方法
         
1 升级中遇到无法解决的错误，如升级程序遇到Bug。 高 升级失败 1）尽早搭建和生产环境一致的测试环境,预先在测试环境演练升级全过程,对于升级中发生的每一种错误找到解决办法；

2）预先制定可靠的系统回退方案，一旦升级失败，可采取快速回退，保障生产业务系统不受影响。
2 升级耗用的时间超过计划停机时间 高 业务系统运营延误 1）在测试环境升级演练中估算生产环境所需的升级时间,适当调整升级方案和计划。

2）升级前进行预演，保障升级最终方案的可行性。

升级后的风险及规避方法

序号 可能遇到的风险 风险等级 可能造成的后果 风险规避方法
         
1 客户端应用与服务器端不兼容 高 应用不稳定或不可用 1）尽管Oracle 11g数据库对10g的应用是兼容的，为保证应用系统在升级后运行的稳定性和高效性，Oracle ACS实施团队建议数据库升级前，应用开发商做较全面的应用功能测试，以验证客户端应用与11g数据库的兼容性。

2）如环境或资源的限制，不能作到应用的全面测试，但也要保证重点业务应用的测试。

3）Oracle ACS实施团队将依据以往的项目实施经验，提供与应用密切相关的数据库重点测试内容，例如设置新的11g数据库参数、数据库分区、数据库并行处理操作、物化视图、Data Guard等测试。

4）建议将客户端也升级到11g，并重新对原有应用进行link操作。
2 部分应用的性能降低 中 部分业务处理无法正常进行 同上
3 数据库运行不稳定 中 生产运营受到影响 1）在测试环境进行充分的压力测试，提早发现潜在问题，通过Oracle的支持找到解决办法；

2）升级后如数据库出现问题，可通过Oracle内部关键支持力量（包括产品研发部门）对系统问题提供及时响应和解决；
4 与CICS等存在不兼容性 高 应用不稳定或不可用 1） 相关厂商提供CICS等支持11g的认证信息

2） 在11g client环境重新编译应用程序

3） 在测试环境充分进行集成测试

人员的风险

序号 可能遇到的风险 风险等级 可能造成的后果 风险规避方法
         
 

1

 项目组成员不能到位 中 项目计划无法正常执行 尽早提出和确定项目实施计划，以便客户方及时安排主要人员的工作
 

2

 项目组成员缺乏足够的知识和技能 低 不能完成项目工作计划所赋予的任务，影响后续工作的进行 安排相关人员的技术交流

强调各类技术人员的配合工作

对项目组人员进行系统的专业培训

项目范围和项目管理的风险

序号 可能遇到的风险 风险等级 可能造成的后果 风险规避方法
         
1． 显著改变项目范围 中 由于需要额外的时间来研究范围变更的后果，因而可能使项目延期 分阶段进行项目的实施。每一阶段都制定切实可行的目标和时间要求。

项目开始前双方同意有关范围目标和实施方法的一般原则，尽量不变。

正式提交变更请求前认真考虑时间、成本和产出的三角制约关系。

按照范围变更的优先级别作不同的处理。
2． 不能及时地审阅和签署项目组提交的文档 中 影响后续任务的开展，可能使项目延期 在审核代表不能履行职责时，应指定代理人。

事先制定有关规则，按照签署文档的重要程度分别指定签字代表。

将需要签字的文档分为较小的若干个内容单一的文档分别签字。
3． 签字代表不能对提交文档作出决定 中 影响后续任务的开展，可能使项目延期 及时提交至有决定权的领导层

请Oracle有关人员作出进一步说明解释

将需要签字的文档分为较小的若干个内容单一的文档分别签字。
4． 项目时间计划比较紧张 中 没有足够的时间对前一个任务进行处理，经常会导致下一任务的延期 合理进行任务划分、任务衔接安排、项目组人员调配

 

 

 

有感于某移动公司的升级案例

2013年8月间，某移动公司在一个晚上成功实施了CRM、账务、计费、渠道等7套核心数据库的11g升级操作，在业界产生了不小的影响。虽然本人没有参与该项目，甚至从未为升级项目而亲临过客户现场，但从客户和Oracle同事们提供的各种讯息和资料中，还是对该项目的整体情况有了基本了解。因此，作为旁观者，本人也冒昧在本书发表一些感悟如下，供大家参考。

回顾当年10g的升级

温故而知新。首先，回顾一下该移动客户当年10g的升级。2007年至2008年间，该客户曾经实施了9i到10g的大规模升级项目。当年该升级项目不仅对客户而言是吃螃蟹的头一遭，而且对Oracle服务团队而言，也是第一次在国内全面、系统地提供升级服务。好在作为全球化公司，我们有GSDK这样的全球升级方法论的指导，因此从项目组建设、项目规划、升级技术方案、测试计划、上线割接方案、上线后支持等，Oracle实施团队都提出了较为全面的方案和实施计划。

例如，在升级技术方案方面，我们团队就针对客户数据库实际情况，提出了“有容灾并迁移主机的升级和割接方案”、“有容灾无迁移主机的升级和割接方案”、“无容灾的升级和割接方案”、“其他升级和割接方案”等4种方案及相应的回退方案。

在测试方面，我们也根据GSDK方法论，强调了应用软件兼容性和性能稳定性测试的重要性，甚至采用了当时刚刚推出的SPA技术进行9i和10g不同平台的性能对比测试。

但是，当年本人曾经去客户现场，与实施该项目的同事进行交流时才了解到：因为缺乏经验的缘故，无论是客户、开发商，还是Oracle自身对升级项目的艰巨性和风险性都认识不足，具体表现就是投入明显不够。Oracle现场实施人员其实就1-2位，开发商更是几乎没有太大投入。虽然升级方案本身设计比较全面，在具体实施中也比较顺利，但升级之后却多次出现Oracle Bug、Oracle 10g新特性运用不当、SQL语句执行计划变化而导致性能衰减等问题。究其根本原因，就是在升级项目中的应用软件测试、10g新特性运用等工作量不够所导致。

总之，该移动客户当年虽然成功实施了9i到10g的升级项目，但却是一路坎坷、一路震荡之后，才逐步达到平稳运行状态的。

有感于11g的升级

首先，感谢和钦佩该移动客户领导和技术人员敢于接收挑战和新技术的勇气和魄力。当然，也是为满足业务发展需求，提高IT系统稳定性，同时充分采用最新的数据库技术，2013年该移动客户再次启动了10g升级到11g的项目。有了9i到10g升级的经验教训，此次升级项目客户明显加大了各方面的投入，以下就是客户专门为此次升级项目而组建的项目组结构：

upgrade17

 

在升级项目实施内容方面，更是几乎涵盖了GSDK方法论建议的每个方面和步骤。在升级方案方面，其实相比当年的10g方案更为简捷，即通过硬件磁盘镜像容灾环境，先原地升级容灾系统，并将容灾中心切换为生产系统，然后重新复制数据到原生产系统，并切换回原生产系统。

相比10g升级项目，此次11g升级项目最大的加强应该是应用软件的性能对比测试，以及11g新特性的运用策略分析。例如，通过11g SPA技术，连续一个月在某10g生产系统进行SQL语句捕获，并在11g测试环境进行回放。据介绍，捕获的语句量达到42万个，而发现性能衰减的语句为450个，并最终有效解决这些性能衰减问题。

在一个晚上成功实施7套核心系统的升级，并在割接之后，没有出现一个性能衰减、Oracle Bug问题，真是一个不小的奇迹！本人事后得到整个项目实施计划，才知道为了这一个晚上的成功，局方、Oracle实施团队、开发商、第三方测试团队等共同艰辛努力了半年多。其中， Oracle实施人天就达到700多。

成功升级之后的某天，本人与该项目的Oracle实施经理沟通时，我问他：“你觉得，这次升级项目投入最大、效果最好的是哪个技术环节？”，他的回答非常简捷：“ SPA！”—— 这就是一线实施人员的宝贵经验！

本章参考资料及进一步读物

本章参考资料及进一步读物：

序号 资料类别 资料名称 资料概述
       
1. Oracle 11g R2联机文档 《Oracle® Database Upgrade Guide》 Oracle 11g R2联机文档中关于数据库升级的不得不看的专门文档。
2. My Oracle Support 《Master Note For Oracle Database Upgrades and Migrations (Doc ID 1152016.1)》 有关Oracle数据库升级和迁移的主文档目录。
3. My Oracle Support 《Complete Checklist for Manual Upgrades to 11gR2 [ID 837570.1]》 手工升级到11g R2的完整操作步骤文档。
4. My Oracle Support 《Upgrade / Downgrade Assistant: Oracle Database/Client (Doc ID 1561791.2)》 Oracle数据库升级/降级及迁移的帮手，帮你快速找到相关文档、技术资源、下载的版本和补丁等。
5. My Oracle Support 《Different Upgrade Methods For Upgrading Your Database (Doc ID 419550.1)》 该文档介绍了DBUA、手工升级、Export/Import、Data Copying、GoldenGate等多种升级方案。
6. My Oracle Support 《Database Server Upgrade/Downgrade Compatibility Matrix (Doc ID 551141.1)》 该文档描述了Oracle数据库版本升级和降级的路线图。
7. My Oracle Support 《Best Practices to Minimize Downtime During Upgrade (Doc ID 455744.1)》 如何降低升级期间的停机时间窗口？该文档给出了相关最佳实践经验。
8. My Oracle Support 《How to estimate the time required to upgrade a database? (Doc ID 739485.1)》 如何估算数据库升级时间？其实升级过程取决于太多因素，Oracle也只能在这篇文档给出一些原则性建议。
9. My Oracle Support 《Oracle 11gR2 Upgrade Companion (Doc ID 785351.1)》 Oracle 11g R2有关升级的辅助文档。
10. My Oracle Support 《Complete checklist for out-of-place manual upgrade from previous 11.2.0.N version to the latest 11.2.0.N patchset. (Doc ID 1276368.1)》 Oracle　11.2.0.2及之后的Patchset是一个完整的版本，如何进行11.2.0.2之后的Patchset安装？该文档给出了完整的手工操作步骤。
11. My Oracle Support 《Master Note for Real Application Testing Option (Doc ID 1464274.1)》 Oracle有关RAT技术的资料汇集地。
12. My Oracle Support 《Master Note: Plan Stability Features (Including SQL Plan Management (SPM)) (Doc ID 1359841.1) 》 Oracle有关SPM技术的资料汇集地。

 

 

Posted

in

by

mac

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *