AFTER LOGON触发器仅在登录时执行一次，无法控制后续表级访问；表级IP限制须用VPD/RLS、视图封装、应用网关或网络层拦截，且需注意NAT导致IP失真及高权限用户绕过等问题。
不能用触发器限制“访问表数据”的IP，只能限制“登录数据库”的IP——这是根本性边界，不是写法问题。
为什么 AFTER LOGON 触发器不作用于表级访问
Oracle 的 AFTER LOGON 触发器只在用户完成身份认证、建立会话时触发一次。它发生在连接建立后、任何 SQL 执行前。一旦登录成功，后续所有对表的 SELECT、UPDATE 等操作都不再经过该触发器——没有“每次查表都校验 IP”这回事。
常见错误现象：写了登录触发器限制 IP，结果用户连上后随便查 scott.emp 都没拦住 → 因为触发器早已执行完毕，控制权交给了会话本身。
- 触发器作用域是会话生命周期起点，不是语句执行点
- 表级访问控制必须靠其他机制：VPD（Virtual Private Database）、RLS（Row Level Security）、视图封装、或应用层网关拦截
- 试图在
BEFORE INSERT ON emp里读sys_context('USERENV', 'IP_ADDRESS')是可行的，但仅能拦 DML，且无法覆盖SELECT场景
真正能按 IP 控制表访问的替代方案
如果目标是“只允许 192.168.5.200 查 orders 表”，必须跳出触发器思维：
-
DBMS_RLS.ADD_POLICY配合自定义函数：在策略函数中返回'IP_ADDRESS = ''' || SYS_CONTEXT('USERENV','IP_ADDRESS') || ''''这类谓词，但注意该值在 NAT 后不可信 - 用视图替代基表：
CREATE VIEW orders_v AS SELECT * FROM orders WHERE SYS_CONTEXT('USERENV','IP_ADDRESS') IN ('192.168.5.200')，然后只授视图权限 - 应用连接池统一做 IP 校验，数据库只认连接池 IP（此时
sys_context返回的是池地址，失去意义） - 网络层拦截：防火墙或云 SLB 做源 IP 透传 + 数据库前端代理验证，比数据库内控更可靠
登录触发器里误用 sys_context('USERENV', 'IP_ADDRESS') 的坑
即使你坚持用登录触发器做粗粒度控制，也得直面现实约束：
- 负载均衡、Kubernetes Service、F5 等中间设备会让
sys_context('USERENV', 'IP_ADDRESS')返回127.0.0.1或空字符串，触发器直接失效 -
DBA、SYS、SYSTEM及拥有ADMINISTER DATABASE TRIGGER权限的用户，登录时不会被触发器阻断（仅告警日志记录） - 客户端看到的错误常是模糊的
ORA-01017或连接中断，而非你RAISE_APPLICATION_ERROR的提示文本 - 触发器里不能查
V$SESSION，否则报ORA-00604；也不能用COMMIT或自治事务写日志
最常被忽略的一点：IP 地址在现代基础设施中本质是“不可信上下文”。真要按来源隔离数据访问，优先考虑网络路径可控的方案，而不是把逻辑塞进数据库触发器里硬扛。
