2021-11-02 17:18:01
如果我们几年前讨论甲骨文升级，会有很多反对意见。现在，如果我们再看这个问题，我认为情况已经改变了。让我试着重新解释这个问题。
Oracle数据库版本背景
首先说一下甲骨文的版本背景。
根据甲骨文的产品线规划，从18c开始的新版本将是年度版本，版本将是发布年份的最后两位数。最初计划作为12.2.0.2的版本是18c，现在正在发布，12.2.0.3将以19c的形式发布。预计Oracle数据库19将是12.2的最后一个版本(“长期支持”版本)。
所以8、8i、9i、10g、11g、12c之后，下一步是18c、19c，现在是2020年。最新版本按照计划还是19c，但是没有20c，不会被嘲笑。
自从V2版本开发以来，我统计了一些版本如下。
版本发布年份。
版本
1979
2.3
1983
3.1.3
1984
4.1.4.0
1985
5.0.22
1988
6.0.17
1992
7.0.12
1997
8.0.3
1998
8.1.5.0
2001
9.0.1.0
2002
9.2.0.1
2003
10.1.0.2
2005
10.2.0.1
2007
11.1.0.6
2009
11.2.0.1
2013
12.1.0.1
2016
12.2.0.1
2018
18.1.0
2019
19c
如果你想从整体上看到不同版本的差异，你可以看看下面的条形图。
这个数字并不能反映版本之间的时间差，只能从版本的变化来看。
仅仅从这个图中，我们就可以看到一个明显的区别，那就是像SQL Server这样的年度版本对版本的差异可以不那么敏感。
Oracle数据库版本规划
我们可以看到有很多版本。如果我们想升级数据库，我们应该选择12c、18c或19c。我们来看一个版本路线图，参考MOS:当前数据库版本的发布时间表(文档ID 742060.1)中的官方文章。
这个图是理解整个内容的核心，可以看到19c的定位是长期版本，而且扩展服务的截止时间是目前最长的。
相比而言18c的生命周期就会短许多，有点像昙花一些的过渡版本，从性价比来看似乎还不如早一些的12.2.0.1这个版本，如何和当时的时间背景联系起来，应该是一批早期用户从11g升级，在没有12.2版本发布时，选择了升级到12.1.0.2，所以看到的12.2.0.1和18c的发布时间也很接近。
值得一提的是，在2020年4月15日，Oracle修改了12.2.0.1的扩展服务截止时间，从2020年12月1日扩展到了2020年3月31日。（Added Limited Error Correction for 12.2.0.1 from Dec 1, 2020 until March 31, 2022）
Oracle数据库服务支持
对于扩展服务，我们可能有些陌生，大体分来，支持的强度分为三个级别：Premier Support（最高优先级的支持）,Extended Support（中等优先级的支持）,Sustaining Support（最低优先级的支持）。
如果和上面的图联系起来，其实就是对于扩展服务打了一些补丁，可以举个例子来说明，比如主流版本是11g,那么会有一个相对稳定产品生命周期，比如是5年，那么在这5年内是官方大力支持的阶段，会修复一系列的版本bug，推出一些改进和新功能，临近产品生命周期，就需要考虑升级，如果不升级服务支持力度上就会打一定的折扣，比如说扩展服务周期是2年，那么2年后正常来说是无法下载一些补丁更新的，如果过了扩展服务周期还没有升级，如果是大客户，花钱继续支持也可以，如果又跨越了多个时段，但是原来的版本支持还是需要，就需要做定制化的支持了。
对于数据库版本来说，10g是个坎，升级到11g是个坎，升级到12c的选择空间从上图来看就比较有限了，目前可选的就是12.2.0.1，18c和19c了。我们来看下这3个版本，我来划一下重点。
| 版本 | 补丁截止时间 | 备注和说明 |
| 19cLong-Term Release | Mar 31, 2023 with no ES/ULAMar 31, 2026 with ES/ULA | Premier Support (PS) ends Mar 31, 2023, Extended Support (ES) fees will be required beginning Apr 01, 2023 through Mar 31, 2026Error Correction / Patching is available through Mar 31, 2026 with paid ES. Without paid ES, patching is only available until Mar 31, 2023. |
| 18cAnnual Release | Jun 08, 2021 | Error Correction / Patching is available until Jun 08, 202118c is not eligible for Extended Support (ES) |
| 12.2.0.1Annual Release | * March 31, 2022 with Limited Error Correction from Dec 1, 2020 | Error Correction / Patching is available until Nov 30, 2020Limited Error Correction (Sev 1 and Security Updates only) is available from Dec 1, 2020 – March 31, 2022 See Note 161818.1 for details.12.2.0.1 is not eligible for Extended Support (ES)Gen 1 ExaCC, OCC DBCS, and ODA will have 3 additional months of support life. The end of life dates for databases on these platforms is: 28-Feb-2021 |
从上面的图来看，为了求稳，我们不是选择最接近的低版本，而是要首选尽可能稳定的大版本，避免后续的大版本改动。如果说得更清楚些，那就是选择19c.
版本的情况基本说完了，我们来看下升级的正确姿势，因为环境的差异，肯定初始版本都不大相同。
Oracle数据库版本升级矩阵
对于11g的数据库来说，如果是11g的最新版本，则可以直接升级到19c,这是一个极大的利好消息，避免了过渡升级带来的潜在隐患和服务不可用过长。
对于12c以上的版本(12.1.0.2以上），则可以直接升级到19c。
升级的过程可以考虑纯手工方式升级数据字典，也可以考虑使用DBUA来做。
Oracle 19c – Complete Checklist for Upgrading to Oracle Database 19c (19.x) using DBUA (Doc ID 2545064.1)
如果使用DBUA来升级，直接升级可以参考如下的表格：
| Source Database | Target Database |
| 11.2.0.4 and Higher | 19.x |
| 12.1.0.2 | 19.x |
| 12.2.0.1 | 19.x |
| 18.1 | 19.x |
对于有些版本来说，则不可以直接升级，就需要过渡，比如你的版本是11.2.0.2，则需要先升级到11.2.0.4之后才可以升级到19c.
| Source Database | Intermediate upgrade path | Target database | ||
| 11.2.0.1/11.2.0.2/11.2.0.3 | –> | 11.2.0.4 | –> | 19.x |
| 11.1.0.6/11.1.0.7 | –> | 11.2.0.4 | –> | 19.x |
| 10.2.0.2, 10.2.0.3, 10.2.0.4, 10.2.0.5 | –> | 11.2.0.4/12.1.0.2 | –> | 19.x |
| 10.1.0.5 | –> | 11.2.0.4/12.1.0.2 | –> | 19.x |
| 9.2.0.8 or earlier | –> | 11.2.0.4 | –> | 19.x |
| 12.1.0.1 | –> | 12.1.0.2/12.2.0.1 | –> | 19.x |
5 尝鲜新版本
此外，如果我们想先尝尝鲜，做下测试
