REVOKE SELECT ON view_name FROM user_name 语法合法但常无效，因用户常通过基表权限、角色或SELECT ANY TABLE等系统权限访问视图；须先查DBA_TAB_PRIVS、DBA_ROLE_PRIVS、DBA_SYS_PRIVS等确认实际权限来源，再针对性撤销。
REVOKE SELECT ON view_name FROM user_name 本身语法合法，但常被误用
很多人以为对视图执行 REVOKE SELECT ON my_view FROM app_user 就能阻止用户查视图，结果发现用户仍能执行 SELECT * FROM my_view。这不是语句写错了，而是权限来源没搞清——用户很可能根本不是通过“直接授予视图 SELECT 权限”获得访问能力的。
常见真实路径有三种：
- 用户被授予了底层表（比如
finance.salary）的SELECT，而视图salary_view只是封装了这张表；只要底层对象权限还在，视图就能跑通 - 用户拥有角色（如
SELECT_CATALOG_ROLE或自定义角色），该角色已包含对视图或其基表的访问权 - 用户被授予了
SELECT ANY TABLE这类系统权限，它覆盖所有用户表和视图（包括DBA_*视图）
查清权限实际来源比盲目 REVOKE 更关键
执行 REVOKE 前，先确认用户到底靠什么在查视图。Oracle 不会告诉你“你正在用哪个权限”，得自己查：
- 查直接对象权限：
SELECT * FROM DBA_TAB_PRIVS WHERE GRANTEE = 'APP_USER' AND TABLE_NAME = 'SALARY_VIEW' - 查角色授予情况：
SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'APP_USER' - 查系统权限：
SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE = 'APP_USER' AND PRIVILEGE LIKE '%SELECT%' - 查角色所含权限（比如
SELECT_CATALOG_ROLE）：SELECT * FROM ROLE_TAB_PRIVS WHERE ROLE = 'SELECT_CATALOG_ROLE' AND TABLE_NAME LIKE 'DBA%'
如果上面四条里任何一条返回了结果，就说明 REVOKE SELECT ON SALARY_VIEW 是无效动作——你在撤一个“没被授予过”的权限。
撤销视图权限真正有效的两种场景
只有当用户确实被显式授予过该视图的 SELECT，且没有其他更高层权限兜底时，REVOKE SELECT ON view_name 才起作用。典型有效场景包括：
- DBA 显式执行过
GRANT SELECT ON finance.salary_view TO app_user，之后想收回 - 用户有
SELECT权限，还带WITH GRANT OPTION，需一并清理下游扩散：REVOKE SELECT ON finance.salary_view FROM app_user+REVOKE GRANT OPTION ON finance.salary_view FROM app_user
注意：Oracle 不支持 CASCADE 关键字，所以即使视图依赖某张表，撤视图权限也不会自动影响那张表的权限状态。
权限变更后旧连接仍可查，别忘了重连
REVOKE 在 Oracle 中立即生效，但仅对新连接可见。如果用户当前已有活跃会话（比如应用连着连接池、SQL*Plus 还开着），他们还能继续查视图，直到连接断开重建。
验证是否真生效，别只看命令是否执行成功，要换一个全新 session 登录再试。必要时可强制终止旧连接：SELECT SID, SERIAL# FROM V$SESSION WHERE USERNAME = 'APP_USER'，再执行 ALTER SYSTEM KILL SESSION 'sid,serial#'。
最容易被忽略的一点：权限回收不是单点操作，而是链路排查。你撤的不是“视图”，而是“用户访问视图所依赖的任意一环”。漏掉角色、系统权限或基表权限中的任一环，REVOKE SELECT ON view_name 就只是在做无用功。
