Oracle 企业应用程序中的DB升级指南/实践

亲爱的团队，

与任何企业应用程序一样，我们有许多内部开发的Microsoft.NET应用程序，它们连接到中央数据库，在本例中为Oracle 10G。在这种环境中，我们有许多基于REST/ SOAP、微服务、Oracle报表、小型工具和实用程序、批处理作业、web应用程序 (IIS托管) 和一个大的基于Windows的应用程序的web服务。

我们计划在这样的环境下将Oracle升级到18C。应用程序需要使用Oracle客户端代码进行升级，以便它们可以连接到较新版本的Oracle。我们不计划升级的模式进行任何更改。

我们的计划是在较低的环境中升级所有依赖的应用程序-更新oracle客户端代码以处理新版本。一旦所有应用程序和oracle报告都迁移到开发环境中，我们将开始迁移到更高的环境，例如UAT，INT，PERF，Pre-Prod和Prod。

在非prod环境中 (除了Prod和非Prod)，我们可以直接从一个版本的Oracle切换到另一个版本，因为我们有多个实例，例如UAT1，UAT2，INT1，INT2等。但是，在Pre-Prod和Prod中这样做既不可能也不可取。在关闭旧数据库之前，我们可能需要进行并行运行。

在这方面，您能否建议在较低环境下升级应用程序时应遵循的良好实践，以及哪种策略更适合prod环境。

谢谢。

问候，
Sumit

一些值得注意的事情

a) 升级到18c是一个坏主意，因为出于支持原因，您将很快再次升级。转到19c，您不必再次升级，直到21世纪20年代末

b) 在我看来，你的非产品机制听起来不错。

c) 对于生产，最终会有一个需要切换的点，并且还有一个不再可能返回的决策点。通常对于后者，这是您开始从客户那里进行交易的那一刻，因为失败并失去交易的公共关系灾难太大了。所以一个典型的场景是:

-宣布中断
-升级/迁移等
-面向测试人员的开放系统/运行一些示例活动/确保基本系统功能全部正常工作
-那就去现实生活吧
-反应并修复遇到的任何问题

一个 * 正版 * 并行运行，你对这两个环境进行实时交易是复杂性的一个很大的飞跃，因为你现在正在寻找一个主动-主动的GoldenGate操作或类似的... 通常这是不值得的努力。

当您进行升级时，请确保您不更改 “兼容” 参数，因为当您这样做的时候，根本就没有后退。如果你把它留在10，那么在整个升级过程中，如果出现了可怕的错误，你可以用几个脚本失败回到你的10g数据库。一旦将兼容参数移至19 (或任何> 10的参数)，则如果没有完整的数据库还原，则不再可能进行故障恢复。

但是我强调...去19c。