exp_full_database和imp_full_database并非导出导入的开关权限，而是允许跨schema全库操作的系统权限集合；真正起效的是directory读写权限与对象select权限的组合。
exp_full_database 和 imp_full_database 这两个角色是 oracle 数据泵（expdp/impdp）权限控制的核心。但要注意：撤销它们并不能真正“限制用户使用导出工具”，而只是阻止其执行全库或跨 schema 操作——普通用户只要拥有对某个目录的 read, write on directory 权限，依然能用 expdp 导出自己 schema 下的对象。
EXP_FULL_DATABASE 角色到底管什么
这个角色本质是一组系统权限的集合，关键包含：
-
SELECT ANY TABLE（读取任意表数据） FLASHBACK ANY TABLEANALYZE ANYQUERY REWRITE- 以及隐式允许访问所有 schema 的元数据
它不控制目录访问，也不决定能否运行 expdp 命令本身。
常见误解是：“只要没给这个角色，用户就导不出”。错。比如：
expdp scott/tiger@pdb1 SCHEMAS=scott DIRECTORY=dp_dir DUMPFILE=scott.dmp
只要 scott 被授予了 READ, WRITE ON DIRECTORY dp_dir，且拥有自己 schema 下对象的 SELECT 权限（默认就有），这条命令就能成功——完全不需要 EXP_FULL_DATABASE。
真正有效的限制手段：目录权限 + 对象权限组合
想让某用户「不能导出」，必须同时切断两个环节：
-
READ, WRITE ON DIRECTORY权限：没有它，expdp启动就报ORA-39002: invalid operation+ORA-39070: Unable to open the log file - 自身 schema 下的
SELECT权限：如果被显式REVOKE SELECT ON xxx FROM scott，导出对应表时会报ORA-39122: Cannot export data from table SCOTT.EMP
所以实际操作中应：
- 不创建通用目录对象供所有人用，而是按需创建专用目录（如
SCOTT_EXPORT_DIR），只授给可信用户 - 对高敏感用户（如应用账号），明确
REVOKE EXP_FULL_DATABASE FROM user_name，再检查是否还残留SELECT ANY TABLE——这个权限比角色更危险，必须一并清理 - 定期审计：
SELECT grantee, privilege FROM dba_sys_privs WHERE privilege LIKE '%SELECT%ANY%' AND grantee NOT IN ('DBA', 'SYS')
多租户（PDB）环境下权限隔离更关键
在 CDB 中，EXP_FULL_DATABASE 是 CDB 级角色；但它在 PDB 内不自动生效。也就是说：
- 即使你在 CDB$ROOT 给用户授了该角色，他在 PDB 里仍无法执行
FULL=Y导出，除非：- 显式在 PDB 内执行
GRANT EXP_FULL_DATABASE TO user_name，或 - 用
GRANT ... CONTAINER=ALL（需SET CONTAINER切换到 CDB$ROOT 后执行）
- 显式在 PDB 内执行
更稳妥的做法是：根本不在 PDB 用户上授予该角色，只靠目录+对象权限做最小化控制。因为 PDB 用户本就不该有跨容器导出需求。
权限模型不是开关，而是链条。断掉任意一环都可能失效；但只断最上面那环（角色），底下链条照常运转。真正起效的永远是最后一公里：目录能不能写、表能不能读。
