数据库管理284期 2025-01-16
数据库管理-第284期 奇怪的sys.user$授权（20250116）
作者：胖头鱼的鱼缸（尹海文） Oracle ACE Pro: Database PostgreSQL ACE Partner 10年数据库行业经验 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVP，ITPUB认证专家 圈内拥有“总监”称号，非著名社恐（社交恐怖分子） 公众号：胖头鱼的鱼缸 CSDN：胖头鱼的鱼缸（尹海文） 墨天轮：胖头鱼的鱼缸 ITPUB：yhw1809。 除授权转载并标明出处外，均为“非法”抄袭
昨天凌晨割接，做一个Oracle向某国产库的实时同步前置配置，主要包含开启数据库最小附加日志、开启表级附加日志以及创建用于同步的用户并授权。但是中间出了点，在启动同步工具的时候报了ORA-01031: insufficient privileges，但是由于授权命令已确认完整执行，因此进行了深度排查。
1 问题
首先还是说明一下环境，这是一套Exadata X8M的环境，两个计算节点，数据库版本为19.21。
经过同步工具日志的排查，是程序在PDB中获取sys.user$信息的时候出现了报错，用户的部分创建语句如下：
create user c##test identified by "Test#!123"; grant connect to c##test container=all; grant select any dictionary to c##test container=all; grant select on sys.user$ to c##test container=all;
这就很奇怪了，按照常理来说，授权增加了container=all子句，是不应该出现这一现象。后面我们统一使用以下语句进行测试，并尝试在测试库（19.22，四节点RAC）中复现：
select count(*) from sys.user$;
2 CDB与PDB
在解决问题的过程中发现，测试语句在CDB中可以正常获得结果，但是在PDB中会显示ORA-01031，常使用下面的命令处理：
alter session set container=pdb_test; grant select on sys.user$ to c##test container=current;
完成后是再连接到PDB中则可以正常执行测试SQL，但该现象在测试库中未复现，由于测试库是19.22，无法排出是否为版本差异，因此回到出问题的库再测试一次，但是在新建用户上也未复现，这就不放出测试过程了，姑且算是触发了一个特定的异常。
3 跨实例
在解决完第一个问题后，发下ORA-01031报错依旧，在进一步的测试过程中发现，授权是在实例1执行的，但是在实例2执行测试SQL的时候会报错，下面是在测试环境中的复现：
3.1 通过scanip访问数据库
sqlplus c##test@scanip/wgbak
发现报错。
3.2 通过节点1的VIP访问数据库
sqlplus c##test@host1-vip/wgbak
可以正常执行。
3.3 通过节点3的VIP访问数据库
sqlplus c##test@host3-vip/wgbak
发现报错。
3.4 在节点3赋权后测试
sqlplus sys@host3-vip/wgbak as sysdba grant select on sys.user$ to c##test container=all;
正常执行。
3.5 小结
这里就不贴出其他实例的测试了，和实例3现象和处理一致。
同时同生产环境处理一致，其余的系统视图同样未出现该问题（比如sys.obj$ , sys.col$ 等），进出现在sys.user$上，这里也不贴出测试结果。
尝试在12.2，19.17的RAC多租户环境中执行也未复现，其他版本未测试。
总结
这是一个发生19c（19.21、19.22）RAC多租户环境授权sys.user$出现的ORA-01031的问题。目前已开SR进行反馈，后续将持续更新。
老规矩，知道写了些啥。
