数据库管理-第293期 奇怪的sys.user$授权+（20250210）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE Partner10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著名社恐（社交恐怖分子）公众号：胖头鱼的鱼缸
CSDN：胖头鱼的鱼缸（尹海文）
墨天轮：胖头鱼的鱼缸
ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

之前的内容可以去看数据库管理-第284期 奇怪的sys.user$授权（20250116）。
目前根据SR的反馈，这个问题已经19c部分版本复现了，而且在23ai中也能复现，在等待SR进一步排查反馈的过程中呢，我也进行了一些尝试。

1 清空shared pool

一般来说授权之后对应信息会写入shared pool中，但如果相关数据在集群同步过程中出现异常，应该是可以通过清空shared pool的方式使其他节点重新读取授权信息。因此在测试库进行相关尝试：

alter system flush shared_pool;

可以看到使用清空shared pool的方式可以解决该问题，但是并不建议在生产环境中使用这一方法，因为会连带清理SQL Plan Cache和其他元数据相关信息，增加硬解析影响性能并短时间增加IO。
通过这个解决方案，应该可以大致推理出，在使用sys.user$ 授权的时候会出现跨实例内存中授权信息不同步的现象，这也是可以通过在不同实例重新授权解决问题的原因。

2 SR反馈

首先在19c的大多数版本（包含最新的19.26）与23ai中，该问题都会出现，通过测试收集的trace分析，没有观察到reload user$ 的权限相关的row cache信息的行为。通过一些Oracle内部的信息检索，可以知晓，根据多个研发部门的调查实例的结论，由于Oracle的内部限制Oracle RAC中跨节点的invalidation时，user$ 这样的bootstrap object不会立即重载，因此，容易出现ORA-1031这样的权限报错问题。
经SR反馈，Oracle的部分编译脚本等都可能会遇到这样的问题，都通过修改脚本，改为访问DBA_XXX视图来解决问题。就本次遇到的问题也建议在需要获取数据库用户信息的时候使用dba_users而不是sys.user$，查询相关视图而不是直接查询基表也更符合数据库的安全规范。

总结

关于sys.user$ 授权的问题，其实是Oracle内部机制的问题，使用sys.user$ 查询用户信息并不合适。
老规矩，知道写了些啥。