必须分两层拦截：先用AFTER LOGON触发器阻断节假日登录，再用表级BEFORE DML触发器校验操作时间；仅靠DML触发器查SYSDATE无法识别已建立连接的会话在节假日期间的修改，且不能处理法定节假日和白名单用户。
用 AFTER LOGON 触发器拦截节假日登录，再配合 DML 触发器控制修改
单纯靠 DML 触发器拦“节假日修改”不可靠——用户可能提前连上数据库，等节假日期间执行 UPDATE 却不触发登录检查。必须分两层：先用 AFTER LOGON ON DATABASE 拦非工作时间连接，再用表级 DML 触发器校验具体操作时间。两者缺一不可。
为什么不能只在 DML 触发器里判断 SYSDATE？
因为 DML 触发器只响应数据变更动作，不感知会话生命周期。常见错误是写这样的逻辑：
IF TO_CHAR(SYSDATE, 'DY', 'NLS_DATE_LANGUAGE=AMERICAN') IN ('SAT', 'SUN') THEN
RAISE_APPLICATION_ERROR(-20001, '周末禁止修改');
END IF;
问题在于：
- 它对已连数小时的会话无效（用户周一连上，周三改数据，触发器不查“是否节假日”，只查“此刻是不是周末”）
- 无法识别法定节假日（如国庆七天假），
DY只返回星期几 - 没区分用户角色，可能误拦 DBA 紧急修复
如何准确识别法定节假日并放行白名单用户？
Oracle 本身无内置节假日表，需自行维护一张 HOLIDAYS 表（字段：holiday_date DATE, description VARCHAR2(50)），然后在 DML 触发器中查询。关键点：
- 必须用
SELECT COUNT(*) INTO v_cnt FROM holidays WHERE holiday_date = TRUNC(SYSDATE)判断当天是否节假日，不能用函数索引或物化视图替代——DDL 触发器里不允许复杂查询 - 白名单用户检查要放在最前：
IF ora_login_user IN ('SYS', 'SYSTEM', 'DBA_ADMIN') THEN RETURN; END IF;，避免权限绕过 - 触发器必须建在目标业务表上（如
emp），且用BEFORE UPDATE OR DELETE——INSERT通常无需限制 - 性能敏感：不要在触发器里查多表、调存储过程，否则每次 UPDATE 都拖慢事务
实际可用的触发器模板（限制 USER_A 在节假日改 emp 表）
以下代码可直接运行，注意替换 schema 名和用户白名单：
CREATE OR REPLACE TRIGGER block_holiday_dml
BEFORE UPDATE OR DELETE ON emp
DECLARE
v_cnt NUMBER;
v_user VARCHAR2(30) := SYS_CONTEXT('USERENV', 'SESSION_USER');
BEGIN
-- 白名单优先放行
IF v_user IN ('SYS', 'SYSTEM', 'DBA_ADMIN') THEN
RETURN;
END IF;
<p>-- 只拦指定业务用户
IF v_user != 'USER_A' THEN
RETURN;
END IF;</p><p>-- 查当天是否节假日
SELECT COUNT(*) INTO v_cnt
FROM holidays
WHERE holiday_date = TRUNC(SYSDATE);</p><p>IF v_cnt > 0 THEN
RAISE_APPLICATION_ERROR(-20001, 'User ' || v_user || ' is not allowed to modify EMP on holidays');
END IF;
END;</p>
这个方案真正起效的前提是：你已经有一张维护准确的 HOLIDAYS 表，并且确保所有业务用户都通过应用连接（而非直连），否则他们可能绕过应用层的时间校验，在触发器生效前就拿到连接句柄。
