必须显式指定SYS Schema执行REVOKE EXECUTE ON SYS.UTL_FILE FROM PUBLIC，否则报ORA-00942；严禁撤销SELECT ANY TABLE，否则STANDARD包失效并引发ORA-06553；撤销前须查DBA_TAB_PRIVS确认权限存在，并用DBA_DEPENDENCIES检查依赖对象。
撤销PUBLIC的EXECUTE权限必须显式指定SYS Schema
直接写 REVOKE EXECUTE ON UTL_FILE FROM PUBLIC 会报 ORA-00942: table or view does not exist——Oracle 要求包名前必须带 schema，且高危包全在 SYS 下。正确写法只能是：REVOKE EXECUTE ON SYS.UTL_FILE FROM PUBLIC。
常见错误是抄文档漏掉 SYS.，或误以为 UTL_HTTP 在当前用户 schema 下。实际所有内置包（UTL_*、DBMS_*、CTX_DOC）都属 SYS，不加前缀就查不到对象。
- 必须用
SYS用户或具有GRANT ANY OBJECT PRIVILEGE的账号执行 - 每条语句单独执行，不要合并成一条（Oracle 不支持多对象批量 revoke）
- 执行前先确认权限真实存在：
SELECT * FROM DBA_TAB_PRIVS WHERE TABLE_NAME = 'UTL_FILE' AND GRANTEE = 'PUBLIC' AND PRIVILEGE = 'EXECUTE'
别碰SELECT ANY TABLE——它不是普通权限
看到 SELECT ANY TABLE 就想 REVOKE？停手。这条系统权限一旦从 PUBLIC 撤销，STANDARD 包立刻变 INVALID，后续任何 PL/SQL 编译、甚至用户登录都可能触发 ORA-06553: PLS-213。
这不是配置错误，而是 Oracle 内部机制：核心包编译时隐式依赖 ALL_* 视图，而这些视图靠 SELECT ANY TABLE 支撑。撤掉它等于拆地基。
- 先查是否真被授予：
SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE = 'PUBLIC' AND PRIVILEGE = 'SELECT ANY TABLE' - 如果存在，不要 revoke——改用最小化授权：只给特定用户查
V_$SESSION等必要视图 - 已撤销导致故障？唯一恢复方式是重新
GRANT SELECT ANY TABLE TO PUBLIC并重启实例（部分版本需重编译STANDARD）
撤销前必须检查依赖对象
撤了 UTL_FILE 权限，但某个报表作业里还硬编码调用 UTL_FILE.FOPEN，运行时直接报 PLS-00201: identifier 'UTL_FILE.FOPEN' must be declared。这不是权限没生效，而是对象没提前评估。
依赖不清理，权限一撤就炸。关键不是“能不能撤”，而是“谁在用”。
- 查哪些对象引用了包：
SELECT OWNER, NAME, TYPE FROM DBA_DEPENDENCIES WHERE REFERENCED_NAME = 'UTL_FILE' AND REFERENCED_OWNER = 'SYS' - 重点关注
TYPE IN ('PROCEDURE', 'FUNCTION', 'PACKAGE BODY', 'TRIGGER')且状态为INVALID的项 - 不要对结果批量
ALTER ... COMPILE——先人工确认是否真需UTL_FILE，能否改用UTL_HTTP或应用层处理
撤销后权限不会自动同步到活跃会话
REVOKE 执行成功，但用户 A 还能继续调用 UTL_FILE？大概率是他在旧会话里没重连。Oracle 权限变更对新会话立即生效，但已有连接缓存权限状态，直到会话结束或主动刷新。
这不是 bug，是设计使然。你不能指望数据库替用户断开连接。
- 测试时务必用新连接验证，不要复用 SQL Developer 里已打开的 worksheet
- 生产环境若需即时生效，可让应用侧重连连接池，或通知用户重新登录
- 注意：撤销角色（如
REVOKE CONNECT FROM scott）不影响已建立的会话，只阻止新建连接
真正麻烦的从来不是语法写错，而是没搞清权限来源路径——PUBLIC 的权限可能来自初始安装、补丁脚本或第三方产品自动授予，盲目撤销等于在没关阀门的情况下拆管道。
