关于作者：
杨志宏，DBAPLUS社区共同发起人，新聚网络首席布道者，对数据库和数据管理有深入研究，合著了《Oracle Core Technology》和《Oracle Exadata专家手册》。
大规模升级即将到来，我们来谈谈使用Oracle 12CR2的体验。
1.升级到12cr2的必要性
随着 2019 年 2 月 13 日发布的 Oracle 19c （Oracle 12.）2.0.3）对于Exadata版本的发布，Oracle 12CR2系统的数据库版本终于迎来了长期支持版本（Oracle 12c的最后一个主要版本），这意味着数据库版本还在Oracle 10G 11G系统中，是时候考虑升级了。
尤其是在 Oracle 11 中2.0.4.以前版本，使用db link系统，一定要升级。
事实上，根据 Oracle 数据库生命周期和版本演进路线图，到 2018 年 12 月 31 日，Oracle 112. 免费延长服务期（免手续费）已结束，部分普通SR账号新遇到的bug补丁将无权限**。
同时，考虑到SCN上限速率算法的变化，12c升级变得更加必要（当然，应用没有改变，或者应用不使用dblink可以忽略）。
每个版本的Oracle都有很多bug，但并不是说Oracle数据库软件不好，而是因为Oracle是OLTP领域的绝对王者，提供了太多的便捷功能，所以bug很多。 因此，在每次升级之前，我们都会浏览修复列表，看看是否有其他人发现并解决了任何新的错误。
到目前为止，Oracle 12系列 2 中的修复补丁数量为 2078 个：
当然，补丁的数量仍然比 oracle 11 少得多2 个 2 系列：
也远低于 Oracle 10系列 2 版本为 26,281（这些补丁均不包含集群补丁）：
这个结果有点出乎意料，12cr2 上的补丁数量比前 2 个版本少了一个数量级。 一种可能是 12cr2 的 bug 少了很多，另一种可能是 12cr2 还没有迎来大规模升级，今年是升级到 12cr2 的最佳时机。
2. Oracle 12C 系统的一些新特性
与 Oracle 11g 相比，Oracle 12c 具有三个被广泛期待的特性：
多租户：12Cr1 中最多允许 252 个租户，12Cr2-19C 中最多允许 4098 个租户，这些租户由最大 PDBS 参数控制。
in-memory option
sharding
从两年多来的案例来看：
分片功能几乎没有使用。
主要原因：在122. SDB只支持一个表族，普通的业务数据库需要有多个表族在 Oracle 19c 中，添加了多表族功能，这可能是一个不错的用途。
内存中选项未大规模使用。
究其原因，一方面是使用场景，另一方面是维护成本，多租户特性成为了这个版本皇冠上的明珠。
多租户是 12c 系统最重要的功能，在 12 中可用1.0.引入了版本 1。 此功能是 12C 版本中最受欢迎的功能，因为它率先在容器数据库中包含许多可插拔数据库 （PDB），每个数据库都可以有自己独立的参数和资源使用限制。
许多企业使用多租户来整合碎片化、占用单个数据库的小型应用程序，大大减少了机器数量，降低了数据库许可成本，并使 PDB 迁移更加灵活。
在使用 PDB 的过程中存在一些 bug，影响相当大。 其中之一是 PDB 在 Data Guard 的备用端运行一段时间后“消失”：
bug 25576813 - v$pdb and show pdbs may not display some pdbs in standby database or ora-65011 on pdb open or pdb datafile on standby with wrong guid ( doc id 25576813.8） 这个错误自 17 年以来一直有一个一次性补丁，但尚未完全修复。完整的修复程序只能升级到 Oracle 18c 或 19c，这将在今年推出。
我一直想知道为什么错误补丁不能与下一个 PSU 中的一次性补丁一起打包
直到 2018 年，一位名叫 Oraguy 的用户才在 Hacker News 上爆料了以下信息：
oracle 12.2 这个版本，有将近 2500 万行的 c**！相比之下，最受欢迎的 NoSQL 数据库是 Redis 50.4 只有 20000 多行**，真的很短，很能干。 ）
oraguy 是这样描述预言机数据库程序员的工作流程的：
获得一个新任务：解决一个新错误。
花了两周时间了解了大约 20 个不同的标志，这些标志以一种非常奇怪的方式创建了这个错误。
尝试添加标志，写几行，并注意不要产生更多错误。
将更改提交到包含大约 100-200 台服务器的测试服务器集群，这些服务器可以编译**、构建新的 Oracle 数据库软件并以分布式方式运行数百万个测试。
回家。 第二天来上班，继续处理其他错误。 测试可能需要 20-30 小时才能完成。
再次回家。 返回工作岗位并检查集群测试结果。 如果进展顺利，将有大约 100 次测试失败;不幸的是，将有大约 1,000 次失败的测试。 随机选择一些测试，并尝试找出您的假设出了什么问题。 可能需要考虑 10 多个标志才能真正了解 bug 的性质。
添加更多标志以尝试解决问题。 再次提交更改进行测试。 再等待 20-30 小时。
来来回回，重复两个星期，我大概明白了这个错误的原因。
有一天，在你差点自杀之前，你发现一个测试已经完全通过了。
再写几百个测试，以防下次坏孩子试图接触一个项目时，他们不会......搞砸你的更改
提交最后一轮测试的结果。 然后提交审核。 审查本身可能需要 2 周到 2 个月的时间。 因此，请继续下一个错误。
2 周到 2 个月后，一切都就绪，最终将合并到主分支中。
如果你看一下上面的 10,000 或 20,000 个补丁，其中一些补丁没有被合并到主分支 （PSU） 中是可以理解的。
PDB 除了用于小型库集成外，还具有在机器资源使用不平衡时不同 CDB 之间热插拔的便利性。
但是，实践证明，热插拔最好在相同版本之间进行，否则可能会有例外。
在 12C 构建 PDB 的语法中，还有一个叫做 path prefix 的新选项，用于将某些对象（目录对象 oracle xml create pfile oracle wallets）限制在特定的目录下。 这个目录前缀，一旦添加，就会一直陪伴PDB到年底，甚至DataPump也无法更改目录，所以添加时一定要谨慎。
在 Oracle 18C 中迁移 PDB 时，请运行 DBMS PDB检查插头兼容性，可能会报告 ORA-7445 [Intel SSSE3 rep memcpy（）] 这是错误28502403 - Oracle 183.0 multitenant: compatibility check does not work。
但是，此错误仅在 18 中出现2 和 183的出现，用最新的18C可以规避这个问题。
随着《国家网络安全法》的实施，企业安全检查更加严格，“定期更改数据库密码”从响应检查转变为严格执行。 这对于11G DG的DBA来说是一件极其痛苦的事情，每次修改主库的密码，都要手动将密码文件同步到每个备份实例中，如果错过了某个实例而不同步，数据就不会同步。
12CR2 引入的新功能是自动将密码文件同步到 Data Guard 备用数据库，当 sys、sysdg 等的密码发生变化时，会更新主数据库中的密码文件，然后将更改传播到配置中的所有备用数据库。
这可以与 11gr2 引入的新参数重做传输用户一起使用，该用户创建一个单独的日志传输授权用户，并授予管理员权限，然后密封帐户。 需要注意的是，此用户名区分大小写。
最新的 Oracle 19c 中还有很多新特性，我最关注的有两点：
自动统计管理
统计管理一直是大型企业数据库管理中的难题，随着表数据的变化，可以实时更新统计数据，防止SQL语句选择次优执行计划（据官网介绍，这是AWS放弃Oracle而选择Aurora的重要原因）。
Oracle 19c 具有内置的专家系统，内置算法可以将应用程序 SQL 历史记录捕获到 SQL 仓库中，识别对新 SQL 有益的回选索引，验证、做出决策、验证、监视自动索引创建，并在自动创建的索引在一段时间内不适合时自动删除它们。
自动创建索引
自动索引创建引入了 dba 自动索引配置的切换视图。 鉴于 19c 目前仅在 Exadata 版本中可用，这两个功能是否会在生产中使用还有待观察。
3.一些应谨慎使用的功能
将事务性生产数据库迁移到 Oracle 12c（包括 Oracle 12Cr2、Oracle 18C、Oracle 19C），有一些功能建议关闭（其中一些从 Oracle 10g 开始就被推荐了），设计理想，现实瘦弱，我们能做的就是帮助尽可能圆润。
下面的默认数据库都是 oracle rac：
1. 实例并行执行
Parallel Force Local：此参数默认为 false。 从理论上讲，将多个节点聚类并处理在一起是最优解。 事实是，多节点并行处理的协调成本较高，节点之间的通信负载较大。 因此，应将其更改为 true，以便在进程级别实现本地化并发处理。
2. 自动内存管理
SGA 自动管理 SGA 目标 从 10G 到 12C 内存级别 自动管理内存目标。 建议将所有核心生产仓库改为手动，几个月未看一眼的非核心仓库可以设置为自动管理。
3. 查询结果缓存
缓存一次，使用100次。 这可能适用于某些“静态”查询系统，这在 OLTP 中很少见。 所有结果缓存最大大小=0。
4. 布隆过滤算法
布隆滤波是布卢姆在2024年提出的，用于检索对象是否在某个集合中，其优点是比其他算法空间效率更高，缺点是具有一定的误识别率。 一旦发现错误，效率就会降低 100 倍，这对于高效稳定的系统来说是不可接受的。
bloom_filter_enabled=false；_bloom_pruning_enabled=false
动态资源重组：每个数据库资源都有其主节点、所有者和请求者，其初衷是根据请求情况动态调整主节点，以减少实例之间的数据传输。
gc_policy_time=0；_gc_undo_affinity=false;"_gc_read_mostly_locking"=false。
5. 创建分段延迟
创建新的数据表时，Oracle 将仅创建此对象，暂时不分配段，并且仅在将第一个数据插入到表中时创建段。 初衷是为了节省存储空间，但这个功能有很多bug。
deferred_segment_creation=false
6. 基于列的内存存储
In-Memory 选项是 12C 的亮点之一，适用于特定应用。
IM 功能需要不定期维护，不仅要关注 IM 中的表是否加载成功、内存区域是否不足，还要在内存资源有限的情况下对存储在 IM 中的表进行优化，及时添加需要的表，删除不需要的表。
一般建议禁用：inmemory size=0;inmemory_query=disable；
四、一些问题和bug
升级到 Oracle 12c 后遇到的一些重要错误建议进行纠正。
问题 1：在 SGA 手动管理模式下，Oracle 会自动偷偷增加共享池（Oracle 192 已解决）。
命中 bug 26405036 大量分配"ges enqueues" and "ges resource dynamic"在共享池中，会自动将共享池的大小从 20G 调整到 200G 以上，直到 SGA Max Size 中没有更多可用空间，并且应用程序将报告 ORA-04031。
解决方法是修补当前的 oracle 185 的补丁也出来了：
临时解决方案如下：
sql> oradebug setmypid
sql> oradebug lkdebug -m reconfig lkdebug
问题 2：主目录中会生成大量跟踪文件或单个超大文件，当空间已满时系统挂起。
问题类似，但它不仅仅是一个错误：
原因1：
trace files generation with message “auto sga: kmgs_parameter_update_timeout gen0 0 mmon alive 1”.
这是一个错误25415713，可以通过安装一次性补丁来修复。
原因2：
trace files generated from rman module with krb messages.
可能是：bug 28174827：rman无条件krb跟踪文件后安装错误22700845修复
bug 28390273 ：rman unconditional krb trace file after patch 27674384
通过更改系统设置事件'trace[krb.*]disk disable, memory disable';解决。
原因3：
kzan: ora-55917 during cli write.
kzan: sys user audit records will written to files now.
KTLI 跟踪：
alter system set event='55901 trace name context off';
alter system set event='trace[recordcompose] off';
alter system set event='trace[filewrite] off';
alter system set event='trace[queuewrite] off';
问题 3：在 RAC 群集环境中，截断一个大表会导致另一个节点挂起。 DBAPLUS 社区有一篇特别的诊断文章：你敢在 Oracle 12c R2 上做一个大表吗？
该错误已在最新版本的 PSU 中修复：
问题 4：升级到 Oracle 12c 18c 后，在早期版本中连接到数据库客户端时报错
ora-28040: no matching authentication protocol/ora-01017: invalid username/password; logon denied
需要先去sqlnetSQLNet的allowed_logon_version_client=8/sqlnet.允许的登录版本 server=8，然后重置密码。 （请参阅 MOS 文档 ID 2296947。1)
五、几个重要参数
还有一些其他推荐的参数，其中大部分是为了避免错误，还有一些是为了关闭某些预言机功能。
ASM初始化参数，将Memory Target设置为2G，将Process设置为200或更高版本。
数据库参数：
serial_direct_read= auto；避免高直接路径读取
lm_tickets=5000；默认 1000，添加 GES 消息工单
px_use_large_pool=true；并行会话使用大型池而不是共享池，从而降低 ora4031 的性能
b_tree_bitmap_plans=false；
sec_case_sensitive_logon=false；禁用密码区分大小写。
gc_defer_time=0；减少热块的进程争用。
datafile_write_errors_crash_instance=false；当在数据文件（sysytem 除外）中发现读写错误时，发生错误的数据文件将脱机，而不会关闭实例。
event='10949 trace name context forever:28401 trace name context forever, level 1:10849 trace name context forever, level 1' ；当数据库关闭时，用户继续输入错误的密码，导致大量库缓存锁定关闭自动串行直接路径读取功能，以防止发生过多的直接路径读取并消耗过多的 I/O 资源。
undo_autotune=false；关闭撤消自动调整。
use_adaptive_log_file_sync=false；默认情况下，将日志缓冲区写入文件模式处于后等待模式，该模式设置为 112.0.版本 3 开始添加轮询方法。 如果禁用此参数，则不允许切换。
fix_control"='14142884:on','8560951:on','8893626:off','9344709:off','9195582:off','9380298:on','13704562:off','16053273:off','8611462:off','17760375:off','17938754:off','8560951:on'
当然，还应该注意的是，这些只是需要注意的参数，在实际环境中还有其他参数应该考虑。 如果您认为在阅读过程中有一些参数需要调整，请在文章末尾留言，为其他同行提供参考。
6. 升级参考文章
核心数据库升级是一个复杂的系统工程，必须经过严格的程序制定、升级测试、性能测试和最终的割接迁移过程，虽然我们经历了上千个系统的12c升级，但每次升级前的测试还是能发现新的缺陷。
有些是面向应用程序的，有些是SQL性能的，有些是数据库软件，甚至有些是存储链接，充分的测试是确保成功升级的唯一保证。
对于大数据量的升级和迁移，甲骨文副总裁Swonger曾发表演讲：不到1天迁移+200TB数据库，这是欧洲电网的案例，采用TTS+EXDP+Perl等手段，值得一看。
友情链接： 对于升级来说，重要的不仅要关心升级本身能否按时完成，还要关心升级的性能、稳定性、可用性、数据一致性和完整性如何，在正式升级割接之前，都应该进行充分的模拟和验证。