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，这才是事后追溯的底线能力。