从文森特·梵高（Vincent Van Gogh）的智慧中汲取灵感，他明智地指出：“伟大的事情不是通过冲动的行动来完成的，而是通过小步的高潮来实现的，”我最近完成了Oracle迁移的关键应用程序。

本文探讨了Oracle升级所需的详尽计划，突出了关键因素。此外，它提供了有关第一手经验的有见地的说明

在升级Oracle升级之前，您要考虑一些要点：

升级类型

在进行升级之前，确定适当的升级路径至关重要。 Oracle文档指定并非所有版本都可以直接升级到Oracle 19c。例如，虽然可以将11.2.0.4直接升级到19c，但必须首先将11.2.0.3移至11.2.0.4，然后再进一步升级。幸运的是，在我们的情况下，可以使用直接升级路径。

参考： Oracle Database 19c Upgrade Guide

现场升级与就地升级

有两种主要升级类型：不可行和就地升级。一个过时的升级涉及在单独的Oracle Clusterware Home中安装较新版本，从而使您可以在将旧数据库复制到新的Oracle 19C的同时使用两个版本。在出现问题的情况下，这种方法可以轻松回滚前版本。另一方面，无地升级覆盖当前的Oracle网格基础架构房屋中的软件，而无需其他硬件。但是，在出现问题的情况下，它不能提供轻松恢复到先前版本的选项。考虑到时间限制和硬件采购挑战，我们选择了就地升级。在本文中，我还将分享我们如何减轻就地升级的潜在弊端。

应用程序的兼容性：

评估应用程序与新Oracle版本的兼容性至关重要。在我们的情况下，我们遇到了两个兼容性挑战：

代码兼容性

Oracle数据库19C不支持使用SID（系统标识符）连接。从Oracle数据库12C开始，Oracle使用服务名称而不是SID引入了一种新的连接方法。服务名称为数据库连接提供了一种更灵活，更可扩展的方法。

连接到Oracle数据库19C时，建议使用服务名称而不是SID以进行适当的连接。此调整可确保兼容性并与Oracle推荐的连接方法保持一致。 SID用作分配给每个Oracle实例的唯一名称，促进标识并连接到特定数据库。使用SID连接时，语法通常遵循格式jdbc:oracle:thin:@host:port:SID。

另一方面，服务名称代表与数据库服务关联的逻辑名称，为建立连接提供了更抽象和适应性的方法。使用服务名称连接时，语法通常遵守格式jdbc:oracle:thin:@host:port/service_name。

驾驶员兼容性

在Oracle升级期间，建议查看Oracle提供的文档，以确定目标数据库发布的支持的驱动程序版本。如果现有驱动程序版本与新的Oracle版本不兼容，则可能需要安装或集成到应用程序中更新的驱动程序版本。这样可以确保应用程序可以建立成功的连接并有效地利用升级的Oracle数据库提供的功能。

我们正在升级到Oracle 19c，因此我们更喜欢使用ojdbc8.jar。

兼容库的Oracle文档中的快速参考。

+----------------------+--------------------------------------+
| ojdbc Driver Version | Compatible Oracle Database Versions  |
+----------------------+--------------------------------------+
| ojdbc6.jar           | Oracle Database 11g                  |
| ojdbc7.jar           | Oracle Database 12c                  |
| ojdbc8.jar           | Oracle Database 12c, 18c, 19c        |
| ojdbc10.jar          | Oracle Database 19c                  |
+----------------------+--------------------------------------+

其他软件组件的兼容性

除了考虑Oracle数据库升级的兼容性外，评估您可能使用的其他组件的兼容性至关重要。例如，如果您使用Informatica，请注意，基于Informatica 10.1文档，它与Oracle 19c不兼容。此信息突出了需要仔细计划升级并进行必要的调整以确保所有组件之间的无缝兼容性。

停机考虑

停机考虑是计划Oracle升级时的关键方面。停机时间的持续时间可能会有所不同，具体取决于数据库的大小，升级的复杂性以及任何特定的要求或约束。仔细评估停机时间对业务运营和用户可访问性的影响至关重要。

在升级过程中，可能需要离线数据库，从而导致服务及其依赖的服务暂时无法获得。这种停机时间会破坏业务活动，影响生产力并可能导致财务影响。

在某些情况下，组织可能会探索减少停机时间的替代解决方案，例如使用备份系统，实施高可用性配置或利用数据复制技术。这些策略可以在升级过程中提供连续的可用性或最小化停机时间。

鉴于我们数据库的实质性大小，使用复制的服务器在就地升级期间不可行。这主要是因为我们的备份数据库旨在作为应急计划，以防在发布期间出现任何问题。因此，我们不得不计划在申请的停机时间24小时。

测试范围

对于不同的应用程序，测试范围可能会有所不同，并且全面定义范围很重要。为了确保平稳的升级，我们进行了完整的回归测试，涵盖了所有接口应用程序和相关功能。根据测试时间表，我们相应地定义了生产日期。

回滚计划

作为我们就地升级策略的一部分，我们需要一个可靠的回滚计划，以防升级期间出现任何问题。我们的后备选项是利用备份数据库。在启动升级之前，我们确保生产数据库和备份数据库是同步的。如果需要回滚，我们将推迟活动，使备份服务器成为主服务器，然后复制数据库以创建另一个备份实例。该计划使我们能够自信地继续前进，因为我们知道我们有可靠的后备选项。

结果

多亏了协作的努力和细致的计划，我们成功地升级了数据库。整个过程是一种宝贵的学习经历，因为它涉及与多个团队协调并与新个人合作以确保成功的结果。