Oracle DBLINK不继承远程角色权限是硬性安全规则，仅识别显式授予连接用户的对象权限（如GRANT SELECT ON sys.dba_tables TO user），角色权限（如DBA、SELECT_CATALOG_ROLE）在DBLINK会话中被主动禁用，防止跨库权限扩散；ORA-00942报错即因未显式授权，须对具体对象（如sys.dba_tables、sys.v_$session）单独授权，或通过封装视图+显式授权绕过。
DBLINK不继承远程角色权限是Oracle硬规则
Oracle的DBLINK在远程库中执行操作时，只使用显式授予该连接用户的对象权限（如SELECT ON schema.table），完全忽略其拥有的角色权限（如SELECT_CATALOG_ROLE、DBA）。这不是配置错误，而是Oracle安全模型的设计选择：角色权限在DBLINK上下文中被主动禁用，防止跨库权限意外扩散。
ORA-00942报错但远程用户明明有DBA角色？查这个
典型现象是：远程用户用sqlplus能正常查dba_tables，但通过DBLINK执行SELECT * FROM dba_tables@mylink直接报ORA-00942: table or view does not exist。原因就是DBA是角色，不是直接授给用户的对象权限。必须显式执行：
-
GRANT SELECT ON sys.dba_tables TO local_user;（注意是sys.dba_tables，不是dba_tables） - 若目标是数据字典视图，且远程库版本≥12c，还需确认
o7_dictionary_accessibility参数为FALSE（默认值），否则即使授了权也无效
PUBLIC DBLINK更危险：创建者角色权限不传递
用CREATE PUBLIC DATABASE LINK时，远程连接凭据来自创建者（比如SCOTT），但SCOTT拥有的角色权限（如SELECT_CATALOG_ROLE）在DBLINK会话中依然不可见。哪怕SCOTT是DBA角色成员，SELECT * FROM v$session@mylink仍会失败——除非单独对SCOTT执行：
-
GRANT SELECT ON sys.v_$session TO SCOTT;（注意是v_$session，基表名带下划线） - 或改用
GRANT SELECT_CATALOG_ROLE TO SCOTT WITH ADMIN OPTION再授权，但这是高危操作，不推荐
替代方案：用视图封装+显式授权绕过角色限制
如果频繁需要访问远程数据字典或系统表，不要依赖角色，而是建一个带权限的视图：
CREATE VIEW scott.remote_dba_tables AS SELECT * FROM dba_tables; GRANT SELECT ON scott.remote_dba_tables TO local_user;
然后本地查：SELECT * FROM scott.remote_dba_tables@mylink。这种方式可控、可审计，且避开角色权限失效问题。记住：DBLINK的权限链只认“谁连上去”和“连上去的人被直接给了什么”，其他一概不认。
