必须用before update触发器校验时间：to_char(sysdate, 'd', 'nls_date_language=american') in ('2','3','4','5','6') and to_char(sysdate, 'hh24') between '09' and '17'。
Oracle BEFORE UPDATE触发器里怎么写时间校验逻辑
必须用 BEFORE UPDATE 触发器，不能用 AFTER UPDATE——后者执行时数据已变更，拦不住写入。核心是提取当前服务器时间的星期和小时，再组合判断。Oracle 的 TO_CHAR(SYSDATE, 'D') 返回周内第几天（1=周日，2=周一…7=周六），但受 NLS_DATE_LANGUAGE 影响，必须显式指定语言避免歧义；TO_CHAR(SYSDATE, 'HH24') 返回 24 小时制小时数（字符串格式），适合直接比较。
常见错误是写成 TO_CHAR(SYSDATE, 'HH24') BETWEEN '09' AND '18'，这会放过 18:00:01 及之后的修改。正确做法是：TO_CHAR(SYSDATE, 'HH24') >= '09' AND TO_CHAR(SYSDATE, 'HH24') ，再配合分钟判断（如需精确到秒，可加 <code>TO_CHAR(SYSDATE, 'MI')）。
- 工作日判断推荐用
TO_CHAR(SYSDATE, 'D', 'NLS_DATE_LANGUAGE=AMERICAN') NOT IN ('1','7') - 工作时间判断用
TO_CHAR(SYSDATE, 'HH24') BETWEEN '09' AND '17'表示 09:00–17:59（字符串比较天然支持左闭右闭） - 务必在触发器开头放行 DBA 账号，比如
IF USER IN ('SYS', 'SYSTEM') THEN RETURN; END IF;，否则维护通道会被锁死
为什么不能在触发器里查表或调自定义函数
触发器执行期间访问其他表（哪怕是 DUAL 以外的表）或调用含查询/事务的 PL/SQL 函数，会引发递归 SQL，轻则报 ORA-00604，重则导致死锁或会话挂起。Oracle 明确限制在 BEFORE LOGON 或 BEFORE UPDATE 触发器中做 DML、DDL 或复杂计算。
实操建议只用纯函数表达式：TO_CHAR(SYSDATE, 'D', 'NLS_DATE_LANGUAGE=AMERICAN') 和 TO_CHAR(SYSDATE, 'HH24') 是安全的，它们不触发任何 SQL 执行；所有逻辑必须写死在 IF 条件里，不封装、不抽象、不复用。
- 禁止写
SELECT COUNT(*) FROM config_table WHERE key = 'business_hours' - 禁止调用自己写的
is_work_hour()函数，哪怕它内部只做字符串比较 - 连
SYSDATE - INTERVAL '8' HOUR这类计算都应避免，除非确认不会触发隐式转换开销
RAISE_APPLICATION_ERROR 报错后应用层能捕获吗
能，但必须用标准错误码和明确提示。Oracle 触发器里用 RAISE_APPLICATION_ERROR(-20001, 'Update denied: outside business hours')，应用层（如 JDBC、OCI）会收到 ORA-20001 错误，并可据此做重试控制或告警。如果只写 DBMS_OUTPUT.PUT_LINE 或漏掉 RAISE，UPDATE 就静默成功了。
容易踩的坑是错误信息太模糊，比如只写 'Operation not allowed'，导致运维无法区分是权限问题、时间问题还是其他业务规则拦截。生产环境必须包含具体时段，例如 'Updates blocked Mon-Fri 09:00–17:59'。
- 错误码建议固定用
-20001到-20999范围，避免与 Oracle 内置错误冲突 - 不要依赖
SQLERRM动态拼接消息，硬编码更稳定 - 测试时用
sqlplus / as sysdba直连验证，绕过 ORM 层确保拦截生效
当前时间（2026-09-28 22:48）是否在允许修改时段
今天是星期一，TO_CHAR(SYSDATE, 'D', 'NLS_DATE_LANGUAGE=AMERICAN') 返回 '2'，符合工作日；但 TO_CHAR(SYSDATE, 'HH24') 是 '22'，远超 '17'。按常规 09:00–17:59 工作时间定义，此刻任何 UPDATE 都会被触发器拒绝。
这个细节常被忽略：触发器永远基于数据库服务器本地时间判断，不是客户端时间，也不是业务所在时区时间。如果服务器设为 UTC，而业务要求按北京时间（UTC+8）控制，就必须用 FROM_TZ(CAST(SYSDATE AS TIMESTAMP), 'UTC') AT TIME ZONE 'Asia/Shanghai' 转换后再取值——但转换本身有性能开销，线上关键表慎用。
