ASH无法直接查IP，因无CLIENT_IP字段；需通过V$SESSION_CONNECT_INFO或应用层埋点（如DBMS_SESSION.SET_IDENTIFIER）关联真实IP。
ASH里怎么查某个IP的活跃会话
oracle ash（active session history）本身不直接存客户端ip，v$session 里的 client_identifier 或 machine 字段可能含线索，但真实ip得靠 v$session_connect_info 或网络层日志补全。直接在 v$active_session_history 里搜 client_ip 字段会失败——它根本不存在。
实操建议：
- 先确认数据库是否启用了
CLIENT_IDENTIFIER：应用连接时需显式调用DBMS_SESSION.SET_IDENTIFIER('192.168.1.100')，否则该字段为空 - 若用的是 Oracle 12c 及以上，且配置了
SQLNET.EXPIRE_TIME和UTL_INADDR.GET_HOST_ADDRESS辅助，可结合V$SESSION的SID关联V$ACTIVE_SESSION_HISTORY的SESSION_ID - 更可靠的做法是查
V$SESSION_CONNECT_INFO，过滤NETWORK_SERVICE_BANNER或CLIENT_CHARSET等上下文线索，再反向匹配V$ACTIVE_SESSION_HISTORY中同一SESSION_ID+SESSION_SERIAL#的记录
为什么用SAMPLE_TIME范围查不到最近1分钟的恶意请求
ASH采样默认每秒1次，但数据只在内存中保留约1小时（具体由 _ASH_DISK_WRITE_THRESHOLD 和 SGA大小决定），且写入 DBA_HIST_ACTIVE_SESS_HISTORY 有延迟——AWR快照通常每小时打一次，中间的“热数据”只在 V$ACTIVE_SESSION_HISTORY 里。
常见错误现象：执行 SELECT * FROM V$ACTIVE_SESSION_HISTORY WHERE SAMPLE_TIME > SYSDATE - 1/1440 返回空，其实不是没数据，而是采样点没对上或被刷出内存。
实操建议：
- 查最近5分钟用
SAMPLE_TIME > SYSDATE - 5/1440，比1分钟更稳妥 - 加
ORDER BY SAMPLE_TIME DESC确认时间戳是否连续 - 如果目标IP已知，优先用
SESSION_ID+SESSION_SERIAL#关联历史会话，比纯时间范围更准
如何把ASH结果和真实客户端IP关联起来
核心矛盾在于：ASH记录的是“谁在做什么”，不是“谁从哪来”。Oracle不会自动记录TCP远端地址到ASH视图，除非你提前埋点或借助外部手段。
使用场景分两种：
- 应用层可控：Java/Python连接时设置
oracle.jdbc.thin.clientInfo或调用setClientInfo("CLIENT_IP", "192.168.1.100")，对应ASH里的CLIENT_ID字段 - DBA侧补救：启用
AUDIT SESSION，配合UNIFIED_AUDIT_TRAIL查CLIENT_IP；或抓包分析监听器日志（$ORACLE_HOME/network/log/listener.log），里面会有类似HOST=192.168.1.100的条目 - 注意：
V$SESSION的OSUSER和MACHINE在共享服务器模式下可能失真，不能直接当IP用
查到可疑会话后怎么快速止损
ASH只能帮你定位“谁在干坏事”，不能直接杀连接。想立刻阻断，得跳出去操作。
性能与兼容性影响：直接 ALTER SYSTEM KILL SESSION 可能引发事务回滚压力，尤其当会话正执行大排序或大量DML时。
实操建议：
- 先确认会话状态：
SELECT STATUS, STATE, EVENT FROM V$SESSION WHERE SID = &sid;，避免杀正在做SQL*Net message from client的空闲会话 - 用带
IMMEDIATE的语法：ALTER SYSTEM KILL SESSION '&sid,&serial' IMMEDIATE;，减少等待 - 更彻底的方式是封IP：在防火墙或数据库监听器配置
tcp.validnode_checking = YES+tcp.invited_nodes = (good-server.example.com)，但这是预防措施，非实时响应
真正难的不是查，是区分“恶意扫描”和“合法重试”——比如一个IP在10秒内发起200次失败登录，可能是暴力破解；但如果每次间隔均匀、SQL都带正确绑定变量，更可能是监控脚本配错了阈值。这种边界，ASH给不出答案，得看上下文。
