<p>应直接查询user_sys_privs视图确认：SELECT * FROM user_sys_privs WHERE privilege = 'CREATE PUBLIC DATABASE LINK';即使用户属DBA角色，该权限也须显式授予，Oracle 12c起不再隐含；无结果即表示当前无法创建public dblink。</p>
如何确认用户是否已有 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 时被权限校验拦截。
