19c ocm依然在准备之中，第三堂和第四堂应该在下周内完成。
本周割接了3次，一次给x8m计算节点换内存（可修复的ecc报错了，没影响生产），两次都是给x8那套升级（就是多灾多难那套）。
1 19.6到19.16
“众所周知”，19.6都是祖上x8部署的时候，出于稳定性、安全性的考虑还是给升个级，从目前使用情况和来自于小伙伴、mos后台的消息，要么升级到19.20（还没出），要么就是到19.16（x9m上用着的，挺稳的）。关于升级第七十六期也有过详细的介绍，这次升级遇到了一些问题，这里尝试在单实例上复现一下：
升级完成后没有注意到pdb的启动状态：
那个库有俩pdb，第一个pdb生产用户基本都有dba权限，少部分没有，因此pdb在restricted状态下是可以连接到数据库的：
而第二个pdb承载用户因为测试不充分，仅仅看到页面显示没问题，没有进行深度测试，知道第二天上生产了才发现有问题通知我这里进行及时处理，在没有办法重启pdb的情况下，只能通过一下命令进行处理：
grant restricted session to username;
2 gis
然而第二个pdb承载业务的不充分测试并不只是带来了一个问题，在涉及gis类操作的时候出现了以下的问题（范例来自于对应的mos document）：
这个还是相对比较好排查，在输入两个ora报错后找到了对应bug：sdo_geom.sdo_area fails with an ora-21779 after 19.16.0.0.220719dbru (doc id 2889251.1)，需要通过patch 34476155来解决这个问题。由于已经是白天生产了，无法打补丁，紧急开sr询问是否有workaround，然而sr的回复通document描述一致，只能通过打补丁实现。因此和业务方沟通，暂时关闭相关功能待到晚上打补丁处理，如果依然异常则回滚到19.6。
当然为了避免gis相关的其他问题在上面bug处理后再出现，与mos后台沟通后最终选用了patch 35204190: merge on database ru 19.16.0.0.0 of 34725493 34476155：
3 问题解决
首先第一个问题还是相对简单，在应用第二个补丁前，再执行下面的命令：
cd $oracle_home/opatch
./datapatch
alter session set container=cdb$root;
@ ?/rdbms/admin/utlrp.sql
alter session set cotnainer=pdb1;
@ ?/rdbms/admin/utlrp.sql
alter session set contaienr=pdb2;
@ ?/rdbms/admin/utlrp.sql
然后使用分步关闭实例并滚动方式应用补丁，完成后再执行：
cd $oracle_home/opatch
./datapatch
最后检查pdb状态也恢复正常了：
业务方对gis相关功能全量测试也没有出现其他问题。
至此本次升级的所有问题解决完成。
总结
不得不说，升级中间restricted那个问题算是我的，没有做好检查工作，还好有应急方案。
但是第二个gis问题，连555.1里面都没有相关描述，我也不可能知道所有的bug，因此业务方测试不充分还是占了大头。
其实两个问题如果业务方都完整测试的话，也不会出现后续问题。
老规矩，知道写了些啥。
