普通用户不能随意导出数据库的关键是回收EXP_FULL_DATABASE系统权限，而非禁用exp命令；该权限缺失时，exp仅能导出自有对象，无法访问DBA_*视图或跨schema段信息，从而阻断全库及他人对象导出。
普通用户不能随意导出数据库，关键不是“禁止 exp 命令”，而是切断其访问跨 schema 元数据的能力——exp_full_database 权限就是那把总钥匙。
为什么 revoke EXP_FULL_DATABASE 不等于禁用 exp
用户仍可执行 exp，但仅限于自己拥有的对象（如 tables=emp 或 owner=scott）。真正起作用的是权限边界：没有 EXP_FULL_DATABASE，exp 就无法读取 DBA_* 视图、无法解析其他用户的段信息（SEG$）、无法构建跨 schema 导出路径。常见表现包括：
-
EXP-00011: table_name is not a valid object（表存在但非当前用户所有） EXP-00003: no storage definition found for segment(0,0)EXP-00023: must be a DBA to do Full Database or Tablespace export
如何精准限制：只收权限，不碰角色
很多管理员误用 ALTER USER username DEFAULT ROLE EXP_FULL_DATABASE，但该语句只是设置默认启用的角色，不解决根本问题。正确做法是显式回收系统权限：
以 SYS 或具备 DBA 角色的用户登录后执行：
REVOKE EXP_FULL_DATABASE FROM scott;
注意以下几点：
- 无需同时
REVOKE IMP_FULL_DATABASE，除非你也要禁用导入能力 - 如果用户还持有
SELECT ANY TABLE，仍可能通过exp导出他人表（虽不推荐，但技术上可行），建议一并回收：REVOKE SELECT ANY TABLE FROM scott;
- 检查是否通过角色间接获得权限：
SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'SCOTT';，再对对应角色执行REVOKE EXP_FULL_DATABASE FROM role_name;
验证权限是否真正失效
不要只看 SELECT * FROM SESSION_PRIVS，它只显示当前会话启用的权限。真实校验需模拟导出行为：
- 尝试导出其他用户表：
exp scott/tiger@orcl file=/tmp/test.dmp tables=hr.employees→ 应报EXP-00009: no privilege to export HR's table EMPLOYEES - 尝试全库导出：
exp scott/tiger@orcl file=/tmp/full.dmp full=y→ 应报EXP-00023 - 确认无残留授权：
SELECT PRIVILEGE FROM DBA_SYS_PRIVS WHERE GRANTEE = 'SCOTT' AND PRIVILEGE IN ('EXP_FULL_DATABASE', 'SELECT ANY TABLE');返回空集才算干净
最易被忽略的一点：Oracle 11g 中，EXP_FULL_DATABASE 是系统权限，不是角色。哪怕你删了角色、改了默认角色，只要该权限仍挂在用户或其任一有效角色下，exp 就能越权工作。回收必须落到权限本身，而不是管理界面里点几下“取消勾选”。
