sys_context('USERENV', 'IP_ADDRESS') 返回为空或127.0.0.1是因连接未走监听器TCP路径，如本地直连或JDBC指向localhost；需改用远程TNS连接验证，并检查NAT/代理或sqlnet.ora中TCP.VALIDNODE_CHECKING配置。
sys_context('USERENV', 'IP_ADDRESS') 返回为空或 127.0.0.1 怎么办
这不是触发器逻辑错了，而是连接方式没走监听器的 TCP 路径。Oracle 只在客户端通过 tnsnames.ora 或完整 TNS 字符串（如 jdbc:oracle:thin:@host:1521/orcl）连接时，才把真实 IP 填进 sys_context('USERENV', 'IP_ADDRESS')；本地直连（sqlplus / as sysdba）、JDBC Thin 指向 localhost、或某些连接池复用本地 socket 的场景下，该值就是空或 127.0.0.1。
验证方法：从远程机器用 SQL*Plus 连接，再执行 SELECT sys_context('USERENV', 'IP_ADDRESS') FROM dual;。若仍为空，需检查是否启用了 TCP.VALIDNODE_CHECKING 干扰了原始 IP 透传，或网络路径中存在 NAT/负载均衡未开启 X-Forwarded-For 类透传机制。
AFTER LOGON 触发器里写日志表报 ORA-04092 错误
在 AFTER LOGON 触发器中直接对普通表做 INSERT 会失败，因为登录上下文不允许 DML。必须显式声明自治事务才能绕过限制：
- 触发器头部加
PRAGMA AUTONOMOUS_TRANSACTION; - 日志写入后必须紧跟
COMMIT;（不能用ROLLBACK，否则登录会话直接中断） - 日志表建议建在
SYSTEM或独立表空间，避免用户权限或配额问题
示例片段：
CREATE OR REPLACE TRIGGER logon_audit_trg
AFTER LOGON ON DATABASE
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
v_ip VARCHAR2(30) := sys_context('USERENV', 'IP_ADDRESS');
v_user VARCHAR2(30) := sys_context('USERENV', 'SESSION_USER');
BEGIN
INSERT INTO login_audit_log (log_time, username, client_ip)
VALUES (SYSDATE, v_user, v_ip);
COMMIT; -- 必须
END;
为什么 DBA 或 IMP_FULL_DATABASE 用户无法被触发器拦截
拥有 ADMINISTER DATABASE TRIGGER 系统权限的用户（包括 DBA、IMP_FULL_DATABASE、SYS、EXFSYS）在触发器抛出 RAISE_APPLICATION_ERROR 后，仍能完成登录——错误只记入告警日志，不阻断会话。这不是 bug，是 Oracle 的安全设计：高权限用户可绕过系统级触发器控制。
这意味着：
- 别指望靠触发器锁死
SYS或运维账号 - 若业务账号被授予了
DBA角色，该账号也失效 - 真正有效的拦截对象是普通应用账号，且这些账号不能有上述系统权限
比触发器更早、更底层的 IP 控制：sqlnet.ora 配置
触发器是登录后执行的，属于“事后拦截”；而 sqlnet.ora 中的 TCP.VALIDNODE_CHECKING 是监听器层过滤，连接请求根本不会抵达数据库实例，性能开销更低、生效更快。
推荐组合策略：
- 全局白名单：设
TCP.VALIDNODE_CHECKING=YES+TCP.INVITED_NODES=(192.168.10.5,10.20.30.40)，堵住绝大多数非法入口 - 精细控制：对特定业务用户（如
APP_USER）再加登录触发器，做用户名+IP 双校验 - 注意：修改
sqlnet.ora后必须lsnrctl reload，不是重启数据库
容易忽略的一点：TCP.INVITED_NODES 和 TCP.EXCLUDED_NODES 冲突时，前者优先；但两者都留空，或只设 EXCLUDED_NODES 而没开 VALIDNODE_CHECKING，配置完全不生效。
