普通用户执行TRUNCATE报ORA-00942或ORA-01031，根本原因在于Oracle不支持按表授予TRUNCATE权限，仅认DROP ANY TABLE这一高危系统权限；安全替代方案是使用AUTHID DEFINER存储过程封装TRUNCATE操作。
普通用户执行 TRUNCATE 报 ORA-00942 或 ORA-01031，不是权限没给全，而是 Oracle 根本不支持“按表授 truncate 权限”——它只认 DROP ANY TABLE 这个高危系统权限。
TRUNCATE 权限机制和 delete 有本质区别
很多人以为 GRANT DELETE ON shop.orders TO dwetl 就能 truncate，其实不行。因为：
-
TRUNCATE是 DDL 操作，不是 DML；Oracle 不提供TRUNCATE ANY TABLE或TRUNCATE ON table_name这类权限 - 合法路径只有两条：
DROP ANY TABLE（太宽泛，DBA 通常拒批），或用AUTHID DEFINER存储过程封装 -
DELETE走的是对象级权限检查，TRUNCATE走的是模式级/系统级权限检查，哪怕你有ALL权限，也不覆盖TRUNCATE
ORA-00942 “table or view does not exist” 的真实原因
这个错误常被误读为“找不到表”，但在 truncate 场景下，它往往掩盖了权限问题：
- 用户
dwetl执行TRUNCATE TABLE shop.orders，即使表存在、同义词也建好了，仍报ORA-00942 - 根本原因是：Oracle 在解析阶段就拒绝了跨用户
TRUNCATE请求，连对象是否存在都懒得查，直接抛出该错误 - 验证方法：用
shop用户自己 truncate 同一张表，一定成功；换dwetl执行，哪怕加了同义词、SELECT权限，照样失败
安全可行的替代方案：AUTHID DEFINER 存储过程
这是生产环境最常用、DBA 最愿意接受的方式，不暴露高危权限，行为可控：
- 在
shop用户下创建一个 procedure，比如proc_trunc_shop_orders，开头写AUTHID DEFINER - 过程体里写
EXECUTE IMMEDIATE 'TRUNCATE TABLE orders'（注意：不能带 schema 前缀） - 然后
GRANT EXECUTE ON proc_trunc_shop_orders TO dwetl - 调用时
CALL shop.proc_trunc_shop_orders()，实际以shop身份执行，权限自然满足
关键点：AUTHID DEFINER 下的过程，权限检查发生在定义者（shop）侧，而非调用者侧；且过程内不能动态拼接 schema 名，否则会触发权限重校验。
容易忽略的坑：外键约束让 TRUNCATE 直接失效
就算权限搞定，执行时还可能卡在 ORA-02266：
- 主表被子表外键引用，哪怕子表当前为空，
TRUNCATE依然拒绝——DDL 不检查数据，只看约束是否启用 - 解决必须分步：
ALTER TABLE child_table DISABLE CONSTRAINT fk_name→TRUNCATE→ALTER TABLE child_table ENABLE CONSTRAINT fk_name - 禁用约束需要
ALTER ANY CONSTRAINT权限，这又是一个独立授权项，不能指望DROP ANY TABLE自动包含它
真正上线前，得确认目标表是否在任何外键链路中，否则 truncate 会静默失败，而开发可能只看到第一层权限错误，根本想不到是约束挡路。
