PL/SQL中无法用普通表触发器拦截TRUNCATE，因其是DDL操作，不触发DML触发器；唯一可行的是由DBA创建ON DATABASE系统触发器，但存在权限绕过和稳定性风险，更推荐权限管控与审计。
PL/SQL 里根本不能用触发器拦 TRUNCATE
Oracle 的触发器（包括 BEFORE TRUNCATE）只存在于系统级事件触发器中，而 PL/SQL 块内定义的行级或语句级触发器（即 CREATE TRIGGER ... ON table_name）对 TRUNCATE 完全无感——它压根不会被触发。
常见错误现象：在表上建了 BEFORE DELETE 触发器，然后以为 TRUNCATE TABLE t1 也会走一遍逻辑，结果毫无拦截效果，数据瞬间清空。
-
TRUNCATE是 DDL 操作，不经过 DML 触发器链路 - 你写的
CREATE TRIGGER tr_t1_before_del BEFORE DELETE ON t1对TRUNCATE零作用 - 想靠“表级触发器”在 PL/SQL 环境中动态控制
TRUNCATE，技术上不可行
Oracle 系统级事件触发器才是唯一可行路径
要真正拦截 TRUNCATE TABLE，必须用数据库级别的系统触发器（ON DATABASE），且只能由具有 ADMINISTER DATABASE TRIGGER 权限的用户（通常是 SYS 或 DBA）创建。
示例脚本：
CREATE OR REPLACE TRIGGER block_truncate_trigger
BEFORE TRUNCATE ON DATABASE
BEGIN
IF ora_dict_obj_type = 'TABLE'
AND ora_dict_obj_name IN ('USERS', 'ORDERS', 'CONFIG')
AND SYS_CONTEXT('USERENV', 'SESSION_USER') NOT IN ('SYS', 'BACKUP_ADMIN') THEN
RAISE_APPLICATION_ERROR(-20001, 'TRUNCATE on protected table "' || ora_dict_obj_name || '" is prohibited');
END IF;
END;
- 注意函数名是
ora_dict_obj_name，不是dictionary_obj_name（后者是 Oracle 10g 旧写法，新版已弃用） -
ora_dict_obj_type和ora_dict_obj_name是系统触发器专用变量，普通表触发器里不存在 - 该触发器对所有会话生效，但无法区分是手动执行还是应用调用——只要 SQL 到达解析层，就会触发
权限控制比触发器更可靠、更轻量
系统触发器虽能拦截，但存在明显短板：它无法阻止 GRANT TRUNCATE ANY TABLE 后的越权操作；一旦触发器本身出错（比如异常未捕获），还可能让整个数据库操作挂起。
更推荐的做法是权限收口：
- 收回非必要用户的
TRUNCATE权限：REVOKE TRUNCATE ON users FROM app_user; - 对高危表禁用
TRUNCATE ANY TABLE，改用细粒度授权 - 生产环境默认不给开发账号
ALTER权限（TRUNCATE需要该权限） - 配合角色管理，如创建
data_maintainer角色，仅在维护窗口临时授权
比起在 SQL 执行路径上加一层拦截逻辑，直接不让语句跑起来，既省资源又少隐患。
TRUNCATE 绕过手段多，别只盯触发器
即使你部署了完美的系统触发器，以下操作依然能绕过：
-
DROP TABLE ... CASCADE CONSTRAINTS+ 重建表结构（不触发TRUNCATE触发器） - 用
expdp导出空数据，再impdp覆盖（DDL 层面绕过） - 直接删数据文件（OS 层面，触发器完全失效）
- 使用
DBMS_REDEFINITION在线重定义表并清空
真正关键的不是“怎么拦”，而是“谁有权限执行”和“有没有审计日志”。AUDIT TRUNCATE BY ACCESS 开启后，每次 TRUNCATE 都会写入 DBA_AUDIT_TRAIL，这才是事后追溯的底线能力。
