如何在Oracle PL/SQL中用触发器实现敏感字段变更前后的差量备份-SQL-PHP中文网

不能只靠一个触发器完成差量备份，必须分别创建before insert、before update、before delete触发器，其中before update中用:old.字段名和:new.字段名安全获取新旧值，需显式逐字段比对（含null安全判断），并写入统一审计表。

如何在oracle pl/sql中用触发器实现敏感字段变更前后的差量备份

直接结论：不能只靠一个触发器完成“差量备份”，必须用 BEFORE 触发器捕获 OLD 值 + 显式字段比对逻辑 + 独立日志表，且 INSERT/UPDATE/DELETE 三类操作需分别建触发器。

BEFORE UPDATE 触发器里怎么安全取旧值和新值

Oracle 行级触发器中，:OLD.字段名 和 :NEW.字段名 是唯一合法访问方式。别写 SELECT ... INTO 回查原表——这会报 ORA-04091（mutating table），也禁止在触发器里 UPDATE 或 INSERT 同一张业务表。

敏感字段必须显式列出，比如监控 id_card、bank_account、phone，不能用循环或动态 SQL 拼接字段名。DDL 变更后触发器不会自动适配，漏列就等于没监控。

NULL 比较必须用 :OLD.phone IS NULL AND :NEW.phone IS NOT NULL 这类写法，= NULL 永远返回 false。

怎么判断“真的变了”而不是空值扰动

差量的核心是“值变化”，不是“语句执行”。常见错误是只要 UPDATE 就记日志，结果 UPDATE t SET name='a' WHERE id=1 即使 name 没变也写一条，日志爆炸。

每个敏感字段都要单独比对，示例逻辑：

IF (:OLD.id_card IS NULL AND :NEW.id_card IS NOT NULL) OR
   (:OLD.id_card IS NOT NULL AND :NEW.id_card IS NULL) OR
   (:OLD.id_card != :NEW.id_card) THEN
  v_changed_fields := v_changed_fields || 'id_card;';
END IF;

注意：!= 在两边都非 NULL 时才安全；字符串比较区分大小写，如需忽略，用 UPPER(:OLD.xxx) != UPPER(:NEW.xxx)。

别把比对逻辑塞进日志表的 INSERT 语句里——可读性差、难调试、无法加注释。

Agent Git Oracle

高级仓库分析与重构指南。基于AI推理识别技术债务与架构反模式。

下载

日志表结构和 INSERT 动作怎么避坑

日志表主键必须是自增 ID NUMBER GENERATED BY DEFAULT AS IDENTITY（Oracle 12c+）或序列 + 触发器，绝不能用 (table_id, operation_time) 这类组合——高并发下时间精度相同就会主键冲突。

字段值统一存 TEXT 类型（Oracle 中对应 CLOB），尤其防 JSON、长地址、加密串被截断。别用 VARCHAR2(4000) 顶替，超长内容直接丢尾。

INSERT 日志必须包含：

operation_type VARCHAR2(10)（填 'UPDATE' / 'INSERT' / 'DELETE'）
table_name VARCHAR2(30)（硬编码或用 ora_dict_obj_name）
row_id ROWID（方便反查原记录）
changed_fields VARCHAR2(500)（拼好的字段列表，如 'id_card;phone;'）
old_value CLOB、new_value CLOB（只存真正变动的字段，JSON 格式更易解析）

不要在触发器里调用函数处理 old_value，比如 MD5 或脱敏——同步执行会拖慢主事务，且失败会导致整个 UPDATE 回滚。

为什么 INSERT 和 DELETE 触发器不能省

用户新增一条带身份证号的记录，或删掉含银行卡号的行，这两类操作同样属于敏感数据暴露/泄露事件，但 BEFORE UPDATE 完全不触发。

BEFORE INSERT 只能用 :NEW，BEFORE DELETE 只能用 :OLD，语法强制隔离，没法绕。软删除（如 UPDATE t SET is_deleted=1）必须在 UPDATE 触发器里加判断：IF :OLD.is_deleted = 0 AND :NEW.is_deleted = 1 THEN ...，否则算漏报。

三个触发器必须共用同一张日志表，但 operation_type 字段值要严格区分，否则下游分析时无法还原操作意图——这是审计链断裂最隐蔽的点。