熟练掌握网站开发技术,免费的正能量视频素材网站,海口建站软件,广东省自然资源厅地址电话数据库管理293期 2025-02-10 数据库管理-第293期 奇怪的sys.user$授权#xff08;20250210#xff09;1 清空shared pool2 SR反馈总结 数据库管理-第293期 奇怪的sys.user$授权#xff08;20250210#xff09;
作者#xff1a;胖头鱼的鱼缸#xff08;尹海文#xff09… 数据库管理293期 2025-02-10 数据库管理-第293期 奇怪的sys.user$授权202502101 清空shared pool2 SR反馈总结 数据库管理-第293期 奇怪的sys.user$授权20250210
作者胖头鱼的鱼缸尹海文
Oracle ACE Pro: Database
PostgreSQL ACE Partner10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVPITPUB认证专家
圈内拥有“总监”称号非著名社恐社交恐怖分子公众号胖头鱼的鱼缸
CSDN胖头鱼的鱼缸尹海文
墨天轮胖头鱼的鱼缸
ITPUByhw1809。
除授权转载并标明出处外均为“非法”抄袭之前的内容可以去看数据库管理-第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$ 查询用户信息并不合适。 老规矩知道写了些啥。
