应直接查询user_sys_privs视图确认:select * from user_sys_privs where privilege = 'create public database link';即使用户属dba角色,该权限也须显式授予,oracle 12c起不再隐含;无结果即表示当前无法创建public dblink。

如何确认用户是否已有 CREATE PUBLIC DATABASE LINK 权限
直接查 user_sys_privs 视图最可靠,避免凭印象判断。执行以下语句即可看到当前用户是否被显式授予该权限:
SELECT * FROM user_sys_privs WHERE privilege = 'CREATE PUBLIC DATABASE LINK';
注意:即使用户属于 DBA 角色,也不代表自动拥有该权限——Oracle 12c 及以后版本中,CREATE PUBLIC DATABASE LINK 不再隐含在 DBA 角色里,必须显式授权。如果查询无结果,说明该用户当前无法创建 public dblink。
撤销已授予的 CREATE PUBLIC DATABASE LINK 权限
只有具备 DBA 权限(如 SYS 或 SYSTEM)的用户才能撤销系统权限。普通用户无法自行放弃该权限,也不能由其他普通用户回收。
撤销命令为:
REVOKE CREATE PUBLIC DATABASE LINK FROM username;
常见疏漏点:
- 误用
DROP PUBLIC DATABASE LINK—— 这是删链接对象,不是撤权限 - 对角色(如
DBA)执行REVOKE但未加FROM ROLE role_name,语法报错 - 撤销后未检查依赖:若该用户已建了 public dblink,撤销权限不影响已有链接运行,但后续无法修改或重建
限制 PUBLIC dblink 创建的替代方案
单纯撤销权限还不够,因为用户仍可能通过 CREATE DATABASE LINK(私有)方式绕过限制,只是链接仅自己可用。若目标是彻底禁止跨库出站能力,需组合控制:
- 同时撤销
CREATE DATABASE LINK和CREATE PUBLIC DATABASE LINK,双权限缺一不可 - 确保远程数据库侧的登录账号(如
CONNECT TO remote_user)本身不具备CREATE SESSION权限,否则即使本地权限受限,dblink 创建时也会在连接阶段失败(ORA-01045) - 网络层封禁目标数据库端口(如 1521)可物理阻断,但属基础设施管控,不属 Oracle 权限体系范畴
为什么不能靠 GLOBAL_NAMES 或 TNS 配置来限制 PUBLIC dblink
GLOBAL_NAMES=TRUE 只影响 link 名称命名规则(要求与远程 global_name 一致),不构成权限控制机制;而 tnsnames.ora 文件内容由客户端或服务端决定,无法阻止用户在 USING 子句中硬编码完整连接串(如 '(DESCRIPTION=(ADDRESS=...))')。所以这两者都不具备访问控制效力。
真正起效的只有系统权限的授予/回收动作。任何试图用配置项“隐藏”或“误导”创建行为的做法,都会在实际执行 CREATE PUBLIC DATABASE LINK 时被权限校验拦截。











