必须用 BEFORE UPDATE 行级触发器拦截转账，因AFTER LOGON仅控制连接建立、不干预后续SQL，且连接池复用导致其无法实时校验；BEFORE UPDATE需FOR EACH ROW、精确判断工作日及时段，并预置节假日表，同时注意时区、跨天事务及运维脚本兼容性。
不能靠 AFTER LOGON 触发器阻止转账，必须用 BEFORE UPDATE 行级触发器 + 时间判断 + 显式拒绝逻辑，否则事务已开始、资金可能已划出。
为什么 AFTER LOGON 触发器对转账无效
登录时间控制只管连接建立，不管后续 SQL。用户 9:00 登录后，18:00 才执行 UPDATE accounts SET balance = balance - 1000 WHERE id = 123，这个转账照样成功。更危险的是：若用连接池，一个连接能复用数小时，AFTER LOGON 根本不重新触发。
常见错误现象：ORA-00604 报错但转账仍提交成功——这是 AFTER LOGON 或 AFTER UPDATE 触发器里抛异常导致的典型“误判”。事务早已进入执行阶段，回滚不了已发生的 DML。
- 真正起作用的拦截点是
BEFORE UPDATE（或BEFORE INSERT，取决于转账是否建交易流水表） - 必须搭配
FOR EACH ROW，确保每一笔更新都检查时间 - 不能只查
SYSDATE小时，还要注意周末和节假日——TO_CHAR(SYSDATE, 'D')的值依赖NLS_TERRITORY，当前是星期六（TO_NUMBER(TO_CHAR(SYSDATE,'D')) == 7），但中国环境可能返回 6，务必先查SELECT TO_CHAR(SYSDATE,'D') FROM DUAL验证
BEFORE UPDATE 触发器中如何安全判断交易时间
核心是把“非交易时间”定义清楚：比如工作日 9:00–17:00，且排除法定节假日。触发器内不能调用复杂函数或查外部表（会引入锁和性能问题），所以节假日需预置到一张轻量表（如 HOLIDAYS），或用硬编码范围（仅限测试环境）。
推荐写法（假设只控工作日+时段，不含节假日）：
CREATE OR REPLACE TRIGGER trf_block_offhours_transfer
BEFORE UPDATE OF balance ON accounts
FOR EACH ROW
DECLARE
v_day PLS_INTEGER := TO_NUMBER(TO_CHAR(SYSDATE, 'D'));
v_hour PLS_INTEGER := TO_NUMBER(TO_CHAR(SYSDATE, 'HH24'));
BEGIN
IF v_day IN (1, 7) OR v_hour NOT BETWEEN 9 AND 16 THEN
RAISE_APPLICATION_ERROR(-20501, 'Transfer not allowed outside trading hours (Mon-Fri 09:00-17:00)');
END IF;
END;注意：v_hour NOT BETWEEN 9 AND 16 表示允许 9:00–16:59，17:00 起禁止——因为 BETWEEN 9 AND 17 会包含 17:00 整点，而银行系统通常以整点为界关闭入账。
- 不要用
TO_CHAR(SYSDATE, 'DY')比较中文 '星期六'，NLS 设置不一致时必失效 - 避免在触发器里查
V$SESSION或调用DBMS_SCHEDULER，开销大且可能死锁 - 如果转账涉及多张表（如
accounts+transactions），触发器要建在资金变动主表上，且确保业务逻辑走同一事务
触发器上线前必须验证的三个边界点
生产环境上线前，光测“白天能转、晚上不能转”远远不够。以下三点漏掉任一，都可能导致资金异常或服务中断：
- 跨天事务：用户 16:59 开始转账，事务耗时 2 分钟，17:01 提交——触发器在
BEFORE UPDATE阶段已校验并放行，但资金实际划出在非交易时间。解决方案：业务层加应用级超时控制，或用 Resource Manager 限制非交易时段的 CPU/IO，让长事务自然失败 - 数据库服务器时间 vs 应用服务器时间：若 DB 服务器时区为 UTC+0，而业务要求按北京时间（UTC+8）控制，则必须用
FROM_TZ(CAST(SYSDATE AS TIMESTAMP), 'UTC') AT TIME ZONE 'Asia/Shanghai'转换，不能简单加减 8 小时 -
INSERT INTO transactions是否也受控？如果转账逻辑是“先插流水再更余额”，那必须在transactions表上另建BEFORE INSERT触发器，否则攻击者可绕过余额表直接插假流水
最易被忽略的一点：触发器启用后，所有 DBA 和运维脚本里的 UPDATE accounts 也会被拦住。日常巡检、数据订正、灾备演练等操作，必须提前用 ALTER TRIGGER trf_block_offhours_transfer DISABLE 临时关闭，操作完立即恢复——别指望“我只在白天操作”这种假设。
