直接上结论，如果要11.2.0.4的数据库直接DBUA升级到19.11，在升级过程中可能会遇到报错 06553: PLS-905: object CTXSYS.CTX_CONTAINS is invalid。需要19.11的ORACLE_HOME先应用补丁32933487, 应用此补丁后，不仅可以躲开报错，还能加速升级过程。
缘起：
在11204升级到19C的过程中会遇到下面的报错，有一个库在升级过程中遇到以下报错，无法正常完成升级
一开始各种搜索，都没找到很好的解释。于是尝试手动编译这两个对象，发现是可以编译成功的。那既然手动编译是没问题的，问题应该是出在中间过程，于是闪回了数据库，再升级一次，在过程中一直关注这两个对象的状态，发现是直接无效了，后面也一直都是无效。失败。手动编译，然后retry 也是不行的，数据库会重新跑一遍升级脚本。同时注意到，脚本是开了4个并行在跑的。会不会是脚本并行的时候，有部分脚本跑的太快，抢跑了呢？ 再次闪回数据库，关闭并行模式进行升级。结果，结果还是失败了。此时其实已经有点想放弃了。以上内容其实说起来简单，但是也花了一上午时间了。
柳暗花明
吃过午饭，重整了一下思路。认真查看起最后一次以非并行模式升级的日志。发现其实真正报错的地方就只有一个。
那么也就是说，只有这个地方是有问题的，同时注意到图片中最后一行字，
Rem END Changes for Bug 31942136
根据以下报错定位到脚本：
SCRIPT = [/u01/app/oracle/product/19.0.0.0/dbhome_1/rdbms/admin/c18.sql]
ERROR = [ORA-06552: PL/SQL: Compilation unit analysis terminated ORA-06553: PLS-905: object CTXSYS.CTX_CONTAINS is invalid
脚本为：$ORACLE_HOME/rdbms/admin/c18.sql
取出包含在bug 31942136 的完整SQL，
发现此段脚本，在
CTXSYS.CTX_CONTAINS
CTXSYS.CONTEXT
有效的情况，是完全可以跑成功的。
注意到在c18的文件头有关于此bug 的一点点描述。
Rem ramekuma 01/06/21 - Backport bug-31942136 from main
也就是在近期才加上的补丁修复。关于此补丁，可以查到信息：
这个补丁最先包含在了19.11里面，也就是我们此时要升级到的目标版本。
为了验证这个问题，我闪回了数据库，并备份，修改了c18.sql 文件，把夹在Rem BEGIN Changes for Bug 31942136 到Rem END Changes for Bug 31942136 的SQL移除了。再次升级，再紧张，焦急的等待中，发现竟然跑过去了。
CTXSYS.CTX_CONTAINS
CTXSYS.CONTEXT
这两个对象也自动VALID，于是趁着DBUA准备跑install patch 脚本之前赶紧把夹在Rem BEGIN Changes for Bug 31942136 到Rem END Changes for Bug 31942136 的SQL手动跑了，完美无报错。升级最后也顺利完成。
后面小心翼翼地更新了SR，请求确认是否是这个问题，以及能否发布补丁或者以移除SQL作为workaround，（无法单独回滚patch 31942136）因为我们升级时间比较赶，准备上生产了。当晚SR 回复，并给出了一个看起来跟我的情况不太符合的补丁。
Patch 32933487: DB UPGRADE FROM 11.2.0.4 TO 19.11 IS SLOW ON DDL OF WRH$ TABLES
应用补丁后，发现这个补丁不仅有效，还加速了升级的速度。
不是非常理解。因为无法看到这个补丁具体的详情。后面拜托大佬，查看到了这个补丁的一些东西。大概能想通吧。
首先，ORACLE 发现为了修复bug-31942136,在代码层面做了更改，同时加了一个主键，这个加主键的动作在12.1以上，是很快的。但是在11.2，就会很慢，而且是根据表的大小会影响快慢。到这里，其实还不太有关系，下面提到了一个关键的点：
所以，11204升级到19.11的问题，还是在于31942136。其实这里也建议，用户考虑使用19.10 升级。
今天看到oracle发布了19.12 的补丁，估计是19.12的用户也遇到了同样的问题。要是oracle的关联搜索再好点，其实可以更快解决问题的。
