临时授予权限须用WITH ADMIN OPTION，否则无法转授且REVOKE前需先清理下游；必须配齐CREATE SESSION等最小权限集；推荐用角色封装以避免扩散风险并简化回收。
临时授予权限必须用 WITH ADMIN OPTION
直接 GRANT 权限给应用用户本身没问题，但“临时提升”意味着后续要由该用户自己去转授、或由 DBA 快速收回——没带 WITH ADMIN OPTION 的权限无法被该用户再授予他人，更关键的是：**它也不能被 REVOKE 掉，除非先撤掉所有下游授予**。
常见错误是只执行：
GRANT CREATE TABLE TO app_user;
结果发现 app_user 不能建表，报 ORA-01031: insufficient privileges——因为缺 CREATE SESSION；或者建了表后其他用户查不了，因为没显式授予 SELECT。所以临时授权得一并配齐最小必要集：
-
CREATE SESSION（否则连不进库） -
CREATE TABLE/CREATE VIEW等实际需要的系统权限 - 如涉及跨用户对象操作，还得加对象权限，比如
GRANT SELECT ON hr.employees TO app_user
REVOKE 收回时要注意级联残留
如果当初用了 WITH ADMIN OPTION，而 app_user 又把权限转授给了 dev_user，那么单纯执行：
REVOKE CREATE TABLE FROM app_user;
不会自动清除 dev_user 手里的同名权限——Oracle 不自动级联回收。此时 dev_user 仍能建表，且 app_user 的权限状态变成 ADMIN_OPTION = NO（查 DBA_SYS_PRIVS 可确认），但权限本身还在。
正确做法分两步：
- 先让
app_user主动REVOKE CREATE TABLE FROM dev_user（如果可控） - 再由 DBA 执行
REVOKE CREATE TABLE FROM app_user - 若已失联或不可控，DBA 只能逐个查
DBA_TAB_PRIVS和DBA_SYS_PRIVS，手动清理所有下游持有者
用角色封装权限比直接授系统权限更安全
直接对用户授 CREATE TABLE 这类系统权限，风险高、难审计、回收粒度粗。推荐用角色过渡：
CREATE ROLE app_maint_role;<br>GRANT CREATE SESSION, CREATE TABLE, CREATE SEQUENCE TO app_maint_role;<br>GRANT app_maint_role TO app_user;
维护完成后，只需：
REVOKE app_maint_role FROM app_user;
这样既避免漏权限，也杜绝了 WITH ADMIN OPTION 带来的扩散风险。注意：角色本身不带 ADMIN OPTION，所以无法被用户转授——这是设计上的安全隔离。
额外提醒：角色默认在会话中生效需重新连接，如需当前会话立即生效，得加 SET ROLE app_maint_role，但该命令不能写在脚本里自动执行（需交互）。
权限变更后务必验证实际效果
很多人收回权限后只查 DBA_SYS_PRIVS 就认为完成了，但常忽略两点：
- 对象权限（如
SELECT ON scott.emp）存在独立视图DBA_TAB_PRIVS，不查这里会漏 - 用户可能有隐式权限：比如属于
RESOURCE角色，而RESOURCE包含CREATE SEQUENCE等，REVOKE单个权限无效
最稳妥的验证方式是用 app_user 账号真实登录，执行预期操作（如 CREATE TABLE t(x INT)），再执行 REVOKE 后重试——报 ORA-01031 才算真正生效。
真正容易被忽略的，是角色嵌套和隐式继承。一个看似干净的 REVOKE，可能因为用户还挂着 CONNECT 或 RESOURCE 角色，导致权限实际未清零。
