AFTER LOGON触发器是限制用户非工作时间登录的最常用方式，但必须创建为ON DATABASE级别、用RAISE_APPLICATION_ERROR主动报错拦截，且仅对新连接生效、不作用于DBA用户。
直接说结论：用 after logon 触发器是最常用、最可控的方式，但必须注意它只拦截新连接，不中断已运行的会话；且对 dba 用户无效，也不能靠它做实时查询限流。
触发器怎么写才不踩坑
核心是 AFTER LOGON ON DATABASE 系统触发器，但写法稍有偏差就会锁错人、锁错时间，甚至导致所有用户无法登录。
-
TO_CHAR(SYSDATE, 'D')返回周几 —— 注意NLS_TERRITORY设置：美国默认周日=1，中国常设为周一=1（ALTERNATIVE或CHINA），生产环境务必先查：SELECT TO_CHAR(SYSDATE, 'D') FROM DUAL; - 小时要用
TO_CHAR(SYSDATE, 'HH24')转成数字再比较，别用'HH'（12小时制）或漏掉TO_NUMBER()导致隐式转换失败 - 必须显式判断用户名：
IF USER = 'REPORT_USER' THEN ...，否则触发器对所有用户生效，DBA 也进不去 - 错误码建议用
-20001到-20999区间，避免和 Oracle 内部错误冲突
为什么不能用 sqlnet.ora 控制登录时段
sqlnet.ora 里的 SQLNET.EXPIRE_TIME 只管空闲超时，tcp.invited_nodes 只管 IP 白名单 —— 它们都不感知“时间”。想靠改 sqlnet.ora 实现“早九晚五放行”，做不到。
- 试图在
sqlnet.ora里加时间逻辑？不行，这文件不支持动态表达式 - 有人试过配合 shell 脚本定时替换
sqlnet.ora再 reload listener？风险极高：监听重启会导致所有连接闪断，且无法精确控制到用户粒度 - 真正能按时间起效的，只有数据库层逻辑（触发器 / Resource Manager）
Resource Manager 能替代触发器吗
能，但目的不同：触发器是“不准进”，Resource Manager 是“让你进来但跑得慢”。适合不想硬拦、只想降级非工作时间查询资源的场景。
- 需先启用资源限制：
ALTER SYSTEM SET RESOURCE_LIMIT = TRUE; - 定义两个 plan：
DAY_PLAN（高 CPU 并行）和NIGHT_PLAN（CPU 限制为 20%，PARALLEL_DEGREE_LIMIT_P1 = 1） - 用
DBMS_SCHEDULER.CREATE_JOB在 09:00 启用DAY_PLAN，17:00 切回NIGHT_PLAN - 注意：plan 切换不立即生效，新会话才应用；已有会话仍沿用旧 plan，除非显式
ALTER SESSION
容易被忽略的权限与边界
触发器本身由 SYS 创建，但它运行时的上下文是登录用户的权限 —— 这决定了它能做什么、不能做什么。
- 触发器内不能执行 DML（如 INSERT 日志表），除非提前给
SYS授予INSERT ANY TABLE，且目标表在SYS下；否则报ORA-00604+ORA-01031 - DBA 角色用户（含
DBA、SELECT_CATALOG_ROLE等）不受触发器限制 —— 这是 Oracle 的安全设计，不是 bug - 触发器不阻断已存在的会话；如果用户凌晨两点连上并一直没断，那他白天还能继续查，直到自己断开或被 DBA 杀掉
- 若需中断运行中会话，得另起定时任务查
V$SESSION，用ALTER SYSTEM KILL SESSION，但这属于运维脚本范畴，不在触发器能力范围内
真正在生产环境上线前，最该花十分钟验证的就三件事：当前 NLS_TERRITORY 下 TO_CHAR(SYSDATE, 'D') 值是否符合预期、用测试账号在边界时间点（比如 8:59 和 9:00）反复登录确认阈值、确认目标用户确实没被授予 DBA 角色。
