以最短的宕机时间升级到Oracle 10g

简介

　　升级硬件通常都很容易，但是升级数据库……毫无疑问，每个人都有着痛苦的经历。一个经验丰富的 Oracle DBA 主要关注的是升级的成功完成和可能导致的宕机时间。成功不仅仅是指升级过程本身正常完成，更重要的是，生产应用程序能在升级后的数据库中无故障地运行。本文中，我们将提供一些建议，通过采用成熟的流程和技术将宕机时间和失败风险降到最低。

　　为什么要升级?

　　Oracle Database 10g 给了我们很多升级的理由。例如，您可以从它的通用可管理性架构中受益。Oracle 10g 在 Advisory Framework 和 Automatic Workload Repository 中包含许多改进和新的选项。Automatic Workload Repository 是为 Oracle 10g 组件提供服务的架构，以便为问题检测和自动优化收集、维护和利用统计信息。

　　同样地，如果您遇到由于错误输入的 SQL 语句导致数据破坏，并需要几个小时来诊断和修复的情况，Oracle 10g 将为您提供强大的人为错误校正功能。例如，Flashback Transaction Query可以帮助您诊断问题并执行事务分析和审核。它能让您轻松地恢复用户或应用程序中的错误。您可以在回收站中使用对象名称查询已删除的表。

　　Oracle 10g 中的其它主要增强功能包括自动化任务。例如，Scheduler 现在可以计划日常管理任务(如收集优化器的统计信息)。

　　Oracle 10g 还支持新的操作系统，并允许您使用更强大的新处理器，从而增强服务器的处理能力。

　　Oracle 10g 还包括改进后的 Real Application Cluster (RAC) 选项。RAC 允许 Oracle 数据库在一组群集服务器上运行任何应用程序。这提供了高水平的可用性和扩展性。如果一个群集服务器出现故障，Oracle 将在其它服务器上运行。

　　因此，如果您有着性能、可用性或常规 OLTP 方面的问题，Oracle 10g 的功能可以帮助您。

　　升级面临的挑战

　　在 24x7 全天候运行的时代之前，升级都安排在周末。用户在星期五下午注销，MIS 会进行完全备份，然后开始升级过程。主要目标是确保系统在星期一早上可以运行，无论是由于升级成功还是不得已，在星期一用户抵达前的几小时内，恢复星期五下午的备份。

　　现在，整个周末宕机是完全无法接受的，因为宕机将意味着大量的收入损失。在电子商务等环境中，周末的收入占据了很大一部分。为了尽可能减少中断的时间，标准升级过程的每一步骤，都需要检查和优化。有没有必要进行冷备份?是否拥有最快速的技术?恢复技术是否同样高效?还有，是否已将升级本身所需的时间降到最低?

　　升级比日常操作需要更多的磁盘空间和内存。如果在升级过程中系统没有这些额外的资源，升级很可能会失败。有些风险是可以预见的。并且，您预见得越多，准备也就越充分。例如，有些失败是因为时间、内存或磁盘空间不足。其它风险可能是由于不可预料的原因，例如介质损坏、备份损坏或电源故障。检查备份的有效性需要花费几分钟，但是这个投入非常值得。设想一下：需要恢复备份的时候，却发现您的备份方案有问题，其结果是灾难性的!

　　虽然人工失误不可能完全排除，但是采用一些重要步骤可将其影响降到最低。首先，确保你的升级小组有足够的精力;其次，保证他们做好了一切准备。

　　最后，也是最重要的，在用户进入系统前，测试升级结果。由于很多用户更重视如何尽快将新系统投入使用，这一步经常都被省略了。有时，这种决定可能是一个严重的错误。

　　简化升级过程

　　利用现有技术，能最大限度地提高成功的机率;预留充足的升级时间，按照最坏的可能，充分测试升级选项以确保成功，将生产系统的中断降到最低。

从 A 复制到 B 　　方法概述 　　1. 创建目标实例 B 　　2. 建立从 A 到 B 的复制链路 　　3. 升级 B 　　4. 恢复从 A 到 B 的复制过程 　　5. 充分测试 B 　　6. 建立从 B 到 A 的复制链路 　　7. 将用户迁移到 B (v10g)(将 A 作为必要情况下的回切服务器) 　　8. 在极短的时间内升级 A 　　创建测试实例 　　第一步是生成生产数据库的副本，以练习和测试升级。这可以通过多种方法完成。最简单的方法是使用磁盘镜像。在镜像环境中，可利用不同的镜像，建立复制进程。将生成的副本加载到另一个系统相同的安装点上，打开新实例，待新的测试实例完全恢复后，可启动该系统上的复制进程。这样，在建立副本过程中堆积在队列中的数据变化，就可以被复制到目标实例中。 　　复制生产系统数据 　　一些在升级后进行的测试，需要复制生产系统的数据变化。这样，您可以在测试实例中获得和生产系统一样的事务类型和数据量。因此，下一步是启动复制过程(如果您还没有这样做的话)。确保您在测试过程中复制了所有的生产表和序列，这样您的测试将是完整的。如果您使用了基于日志的复制产品，例如 Quest Software 的 SharePlex®for Oracle，要确保在测试实例中禁用触发器。触发器不应该修改目标数据，因为触发器在生产系统中产生的数据变化，同样被记录在在线日志中，并且已经被复制。

进行升级

　　当您启动复制过程后，可以开始在测试实例中进行升级。为此，需要停止测试实例的数据更新，并允许复制产品将捕获到的生产系统更新暂存到队列中。按照 Oracle 的说明进行升级，完成后恢复复制进程，将队列里的事务复制到新的 Oracle 10g 实例中。

　　初步检查

　　复制生产系统数据是测试新的升级实例的重要开端，因为它包含了大量数据和多种事务类型，如果不借助工具，这些数据可能需要开发人员花费大量的时间才能复制。作为针对该实例的唯一一种测试，需要将这种复制持续至少两天。接下来，开始运行只读测试，检查您的报表和查询与 Oracle10g 的兼容性：是否所有报表和查询都能在 Oracle 10g 上正常运行?

　　实施所需的 ORACLE 10g 新特性

　　Oracle 10g 包括许多新功能。实际使用一下您需要的一些新功能。

　　在 Oracle 10g 上测试更新后的应用程序

　　毫无疑问，这是任务中最繁重的部分：检查所有的应用程序(套装和自开发应用)是否都能与新的数据库兼容。首先，列出要测试的所有应用程序。您可能会按照重要性或复杂性组织列表。(也可能需要根据一些应用程序的相关性组织列表。)相对于列表的顺序，其完整性更为重要。建立一个可以更新的列表(包括日期、时间和结果)十分重要，因为您可能会忘记实际测试过的应用程序，而不是测试本身。确保包括定期使用的特殊程序，例如月底、季度末和年底的业务流程。

　　

　　在测试实例中运行需要更新数据的应用程序时，先应停止复制进程。打开开发诊断工具，以确定哪些表和序列受到应用程序的影响。然后，运行测试，并检查其结果。在测试实例中进行的测试，会造成生产实例和测试实例的数据不一致，因此您需要还原测试环境使得两边的数据一致。您用于还原测试环境的方法，取决于项目的可用技术和测试所修改的范围。如果您测试的应用程序对一些大型表只做了少量修改，对其再同步的一个快速方法是使用DataEquator，一种用于 SharePlex for Oracle 的比较和修复的程序。它可以比较一对表的数据，并生成脚本，使第二张表与第一张表相匹配。您可以在即将重置测试环境时运行该脚本。另一个选项是在测试前将测试数据库存储到磁带中，然后在之后恢复它(如果改动较多并且表之间有很多交叉)。你还可以使用 Oracle 10g 中新的闪回机制来回滚测试。

　　另一个方法是通过生产系统重新同步数据。为此，您需要知道在测试实例中您所进行的测试都对那些测试实例中的 Schema 进行了修改，包括升级本身的修改，以及您所选择的 Oracle 10g 功能所做的修改。Quest Software 的 Toad for Oracle 可以通过比较两个系统的 Schema 和创建变化脚本来简化这个过程。(您无需在生产系统中运行脚本，但您将在生产系统的备份中运行它。)准备好该脚本后，您可以重复创建测试实例的过程：中断生产系统的镜像，将副本移动到测试系统中，将其安装在相同的安装点，并打开该实例。将使用镜像技术创建的映象与复制队列中包含的事务进行同步，删除镜像中已经包括的事务和更新。最后，运行脚本以提交 Schema 修改，成功完成操作!您已经在 Oracle 10g 实例中建立了一个全新、一致的生产数据映象。

　　当您完成了所有的测试环节后，再一次将生产实例与测试实例进行重新同步。现在您可以开始将用户迁移到运行 Oracle 10g 的系统中了。

将生产系统迁移到 Oracle 10g

　　首先激活一个从 Oracle 10g 到 Oracle 9i 的反向复制链路。要避免为某个事务设置无限循环。Quest Software 的 SharePlex for Oracle 默认禁用这种复制循环。如果您使用了另一种复制产品，请检查以确保它不会存在这种无限循环的复制。当生产活动较空闲时，暂停生产系统并等待所有事务都同步到 Oracle 10g 实例中。当所有事务都同步以后，就可以让用户在 Oracle 10g 系统中工作了。

　　让用户使用新版本的软件和数据库，能帮助您检查测试期间遗漏的问题。不应该有大问题出现。然而，您还应准备一个备份计划，作为重大问题出现时的备用方案。由于您现在有一条从 Oracle　10g 复制到 Oracle 9i 的反向复制链路，您可以将用户重新定向到备份系统。Oracle 9i 实例反映了所有的用户更新，此前应用程序可以在该实例中成功运行。紧急情况下，如果重要的应用程序在 Oracle 10g 中遇到了重大问题，您可以将用户回切到 Oracle 9i 中，保持业务的继续。同时，您的 MIS 职员可以确定需要修改的地方，以便使应用程序与 Oracle 10g 完全兼容，修正错误并为将来再次将用户转移到 Oracle 10g 做准备。

　　更新备份系统

　　一旦您的生产环境已经在 Oracle 10g 数据库和应用程序中成功运行足够长的时间，让您充分信赖，您会希望把备份系统更新到 Oracle 10g。这个过程比最初的升级更快更容易，因为您的数据和应用程序已准备就绪。您只需为另一系统建立一个 10g 的副本。

　　基本上，您将重复创建测试实例时所进行的过程，只是方向正好相反。您将在 Oracle 10g 的实例系统中把存储镜像分成两部分，将 10g 数据库存储的副本转移到备份系统中，将其加载在相同的安装点，并打开实例。接下来，您将让复制产品进行相应的审核，将复制队列中通过镜像创建实例已经复制的那部分事务删除，然后继续复制过程。

　　在将用户转移到原始生产系统 (A) 之前，您需将复制过程设置为相反方向(从 A 到 B)。这将使您可以继续正常的操作。

　　然后，当您准备就绪时，只需暂停生产系统，将事务定位到备份系统，并重定向用户即可。

　　

　　复制就绪后，您将拥有第二个实例用于日常报表和查询，以优化 OLTP 性能和可用性。你可以在生产系统中执行日常维护，而无需中断生产活动，因为它可以在备用系统中运行。

　　结论

　　通过采用成熟的策略和专门的辅助工具，可以将升级需要的宕机时间降到最低。客户使用这种方法平均减少了 94% 的宕机时间。采用以上推荐的解决方案后，对生产用户的中断仅限于新旧两套系统的切换，以及激活复制链路的时间(通常不超过 1 分钟)。在升级完成并进行了充分的测试后，才将用户转移过来，所有由于升级过程意外故障所引起的延误都得以消除：这主要得益于升级没有直接在生产系统上进行。