revoke delete权限不能完全阻止用户删数据。因用户可能通过角色继承delete any table等高危系统权限，或表名大小写、schema未匹配导致撤销无效，需查权限来源并实际测试验证。
revoke delete 权限是否真能阻止用户删数据？
不能一概而论。直接执行 revoke delete on schema.table from user; 只会撤销显式授予的 delete 对象权限，但若该用户属于某个角色（如 dba、resource 或自定义角色），而该角色拥有 delete any table 系统权限或对目标表的 delete 权限，那么撤销对象级权限毫无效果——用户仍可删除。
实操前务必先查清权限来源：
SELECT grantee, privilege, admin_option, grantable
FROM dba_tab_privs
WHERE table_name = 'YOUR_TABLE' AND owner = 'SCHEMA_NAME' AND privilege = 'DELETE';
<p>SELECT grantee, privilege, admin_option
FROM dba_sys_privs
WHERE privilege IN ('DELETE ANY TABLE', 'DROP ANY TABLE') AND grantee IN (
SELECT granted_role FROM dba_role_privs START WITH grantee = 'TARGET_USER' CONNECT BY PRIOR granted_role = grantee
);</p>
撤销对象级 DELETE 权限的正确写法
仅当确认目标权限是直接授予（非通过角色继承）时，才用 REVOKE 撤销。注意三要素必须完全匹配授予权限时的定义：表名大小写、schema 名、大小写敏感性（若表名含双引号建表，必须严格匹配）。
-
REVOKE DELETE ON scott.emp FROM alice;—— 正确，假设emp是小写普通表 -
REVOKE DELETE ON SCOTT.EMP FROM alice;—— 若原表是小写创建，此语句不报错但实际不生效（Oracle 自动转大写后找不到匹配项） -
REVOKE DELETE ON "MyTable" FROM alice;—— 必须加双引号，且大小写与建表时一致 - 不能省略 schema：直接写
REVOKE DELETE ON emp FROM alice;会报错ORA-00942: table or view does not exist
为什么 REVOKE 后用户还能删？常见漏点
最常被忽略的是 DELETE ANY TABLE 这类高危系统权限。它覆盖所有表，优先级高于对象级权限控制。哪怕你 revoke 了某张表的 DELETE，只要用户有这个系统权限，照样能删。
- 检查用户是否直接受权：
SELECT * FROM dba_sys_privs WHERE grantee = 'ALICE' AND privilege = 'DELETE ANY TABLE'; - 检查其角色是否带该权限：
SELECT role FROM dba_role_privs WHERE grantee = 'ALICE';，再对每个 role 查dba_sys_privs - 注意
WITH ADMIN OPTION：如果用户曾被授予权限并带该选项，ta 可能已把DELETE ANY TABLE转授给他人，甚至自己保留副本 - 回收系统权限需 DBA 权限：
REVOKE DELETE ANY TABLE FROM alice;，普通用户无权执行
撤销后如何验证是否真正生效？
别只信查询结果，一定要用目标用户实际连库测试。用 sqlplus alice/password@db 登录后执行：
DELETE FROM scott.emp WHERE rownum = 1;
若返回 ORA-01031: insufficient privileges 才算成功；若报 ORA-00942，说明连表都看不见，可能是 SELECT 权限也没给，和 DELETE 撤销无关。
容易被绕过的点：用户若有 INSERT + UPDATE 权限，可能通过“逻辑删除”（如加 is_deleted 字段）规避限制；若有 DROP 权限，干脆删整张表——所以权限清理必须成套评估，不能只盯一个 DELETE。
