如何通过ASH追踪特定客户端IP_分析机器发起的大规模恶意请求-Oracle-PHP中文网

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给不出答案，得看上下文。