禁用student表所有触发器应执行ALTER TABLE student DISABLE TRIGGER ALL；该语句仅影响DML触发器，不删除定义，需ALTER权限，不可回滚，启用时用ENABLE TRIGGER ALL。
禁用 student 表上的所有触发器
直接执行 ALTER TABLE student DISABLE ALL TRIGGERS 即可。这条语句会将该表关联的所有触发器状态设为 DISABLED，后续对该表的 INSERT/UPDATE/DELETE 操作不会激活它们。
注意：DISABLE ALL TRIGGERS 不影响触发器定义本身，也不删除任何对象；它只修改数据字典中 STATUS 字段值（查 USER_TRIGGERS.STATUS 可确认）。
- 必须对
student表有ALTER权限 - 不能在事务中执行后回滚——该操作立即生效且不可逆（除非手动
ENABLE） - 若表上有
INSTEAD OF触发器（比如建在视图上），此语句不作用于它们，只影响 DML 类型触发器
重新启用 student 表上的所有触发器
对应命令是 ALTER TABLE student ENABLE ALL TRIGGERS。执行后，所有之前被禁用的触发器恢复为 ENABLED 状态，下一次满足触发条件时就会正常执行。
常见误操作：有人试图用 ALTER TRIGGER xxx ENABLE 逐个启用，这在批量场景下效率低且易漏；而 ENABLE ALL TRIGGERS 是原子性操作，更安全可靠。
- 启用操作不要求触发器源代码可访问，只要对象仍存在、状态字段可写即可
- 如果某个触发器因依赖对象失效（如调用的函数被删），启用后状态可能仍是
INVALID，需额外ALTER TRIGGER xxx COMPILE - 启用前后建议查一遍
SELECT TRIGGER_NAME, STATUS FROM USER_TRIGGERS WHERE TABLE_NAME = 'STUDENT'
为什么不用 ALTER TRIGGER 单独操作
单独对每个触发器执行 ALTER TRIGGER t1 DISABLE 或 ALTER TRIGGER t2 ENABLE 完全可行，但实际运维中容易出错：
- 需要先查出全部触发器名：
SELECT TRIGGER_NAME FROM USER_TRIGGERS WHERE TABLE_NAME = 'STUDENT' - 脚本拼接或复制粘贴时易漏掉某一个，尤其当表有 5+ 个触发器时
-
ALTER TRIGGER无法跨 schema 批量操作；而ALTER TABLE ... ALL TRIGGERS天然绑定表级上下文 - 某些系统触发器（如基于物化视图日志的）可能未列在
USER_TRIGGERS中，ALL TRIGGERS更全面
禁用期间要注意的副作用
触发器被禁用不只是“跳过一段逻辑”那么简单。比如业务中依赖触发器自动生成审计字段、校验约束、同步下游表，禁用后这些行为全部中断，且不会报错——数据看起来“成功写入”，但隐含逻辑已丢失。
- 禁用前务必确认当前无并发 DML 操作，否则可能出现部分语句走触发逻辑、部分不走的中间态
- 禁用后如果做了 DML，又忘了启用就提交了应用变更，后续排查数据不一致会非常困难
- Oracle 19c 中，
DISABLE ALL TRIGGERS不影响BEFORE STATEMENT或AFTER STATEMENT的执行时机判断，只是跳过整个触发体
最常被忽略的一点：禁用操作本身不记录在 DBA_AUDIT_TRAIL 中，除非你额外开启了 DDL 审计；所以临时禁用后若引发问题，很难追溯是谁、何时执行的。
