再次感谢 T-Systems 的 Peter Lehmann 向我强调了这个问题。修补后，空间索引创建失败并显示 ORA-13249。彼得的客户非常担心。但是看看可能是什么原因造成的，以及我们如何修复它。
发生了什么？
Peter 将系统从 19.10.0 修补到 19.11.0。这个数据库之前从12.2.0.1升级到19.7.0，之前打过补丁到19.9.0。该数据库仅安装了 Oracle Locator，但未安装 Spatial。包括数据补丁在内的修补工作正常。一切似乎都很好。直到客户尝试创建一个带有空间索引的新表。
CREATE INDEX cola_spatial_idx_cs ON cola_markets_cs(shape)
INDEXTYPE IS MDSYS.SPATIAL_INDEX;
CREATE INDEX cola_spatial_idx_cs
*
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13249: Error executing stmt: INSERT INTO MDSYS.SDO_INDEX_METADATA_TABLE
(SDO_INDEX_OWNER, SDO_INDEX_TYPE, SDO_LEVEL, SDO_NUMTILES, SDO_MAXLEVEL,
SDO_COMMIT_INTERVAL, SDO_INDEX_TABLE, SDO_INDEX_NAME, SDO_INDEX_PRIMARY,
SDO_TSNAME, SDO_COLUMN_NAME, SDO_RTREE_HEIGHT, SDO_RTREE_NUM_NODES,
SDO_RTREE_DIMENSIONALITY, SDO_RTREE_FANOUT, SDO_RTREE_ROOT, SDO_RTREE_SEQ_NAME,
SDO_INDEX_DIMS, SDO_LAYER_GTYPE, SDO_RTREE_PCTFREE, SDO_PARTITIONED ...
现在他们检查了之前版本 (19.10.0) 中的相同代码，一切顺利。
Peter 搜索了 MOS 并找到了潜在的“解决方案”，例如MOS Note: 2752845.1 – Spatial Index Creation Fails with ORA-13249, ORA-06512 After Applying 19.10.0.0.210119DBRU。但是当我检查底层的错误条目时，在我看来这不是完全相同的问题。
此外，Peter 对推荐的解决方案非常不满意：
安装 Oracle Spatial，它将运行新的/升级的脚本，从而使用新结构重新创建 MDSYS.SDO_INDEX_METADATA_TABLE。
当您为最终客户运行大量多租户环境时，这看起来不是很吸引人。
更糟糕的是，发生这种情况的 PDB 不再不受限制地打开。
Oracle 支持人员怎么说？
当然，Peter 确实打开了 SR。这导致了我所谓的“30 秒 SR”，分析师告诉您“这不受支持。再见。”。当然不是那么短，但建议的解决方案与注释中的基本相同：安装空间，一切都很好。S patial 自 2019 年 12 月起无需许可。当然，将选件安装到数百个 PDB 中这一事实是一项资源密集型工作，而且还需要最终客户的同意，并且可能会导致额外的维护工作。因此，并不总是希望在数据库中有更多选项。
正如您作为博客读者所知，更多选项会使您的升级需要更长的时间。
但它变得更好了。支持工程师告诉 Peter，除非 Peter 安装 Spatial，否则他不会做任何进一步的工作。这已被粘贴到 MOS Note 中。多亏了我在空间开发部门的同事，这些已经被删除了。
发展怎么说？
多亏了空间开发团队的同事，我们很快就可以诊断出这个问题的根本原因。当 Spatial 修复被卷入 RU 时，数据补丁会检查 SDO 是否存在于 REGISTRY$ 中。如果不是，datapatch 不会运行脚本。到现在为止还挺好。
但是当您只有定位器，并且没有安装 SDO（空间数据选项）时，它在 REGISTRY$ 中没有条目。所以 datapatch 不知道它仍然需要运行这个特定的脚本。当然，这不是好事，也是一个问题。但目前责任方正在讨论未来如何解决这个问题。
所以在我们的例子中，一个二进制补丁被应用到了新家。但是 SQL 部分没有运行，因此数据库无法创建此索引。
解决方法是什么？
解决方法非常简单直接——运行：
alter session set current_schema=MDSYS;
@@?/md/admin/prvtimd.plb
在 PDB 或发生这种情况的数据库中。然后你需要用utlrp.sql重新编译——一切都会再次正常工作。
我怀疑（但我自己还没有测试过）您还需要在 CDBROOT 和 PDBSEED 中运行它，以便将来的新 PDB 避免出现任何问题。因此 catcon.pl 是确保您也在系统容器中执行脚本的工具。
