直接查v$session与v$sesstat联合视图可获会话级资源消耗明细，关键指标包括CPU used by this session（反映内核计算压力）、session pga memory max（超200MB持续增长提示内存问题）、consistent gets与physical reads（比例＞15%暗示缓存失效或全表扫描），需通过两次采样做差值观察变化趋势，并关注ACTIVE会话的sql_id关联v$sql定位实际SQL。
直接查 v$session + v$sesstat 联合视图，就能看到每个用户会话当前的资源消耗明细，比如 CPU、逻辑读、物理读、PGA 内存等。 不需要额外工具或 GUI，一条 SQL 就能定位谁在吃资源。关键不是“查什么”，而是“查哪几项才真正反映实际压力”。
查具体用户当前的 CPU 和内存占用
Oracle 中最常被误读的是“CPU used by this session”——它只统计该会话在 Oracle 内核中消耗的 CPU 时间（不含 OS 调度等待），但对排查高负载非常有效。配合 session pga memory max 可判断是否内存暴涨：
-
session pga memory max超过 200MB 且持续增长，大概率是排序/哈希连接没走索引，或 PL/SQL 大集合未分批处理 -
CPU used by this session值远高于其他会话（比如 > 1000000），说明该会话正在密集计算，不是简单等待 I/O - 注意：
v$sesstat的值是累计值，不是瞬时速率；要观察变化趋势，需间隔几秒两次查询做差值
查谁在大量做逻辑读或物理读
逻辑读（consistent gets）高 ≠ 慢，但若伴随高 physical reads，基本可断定缓存失效或 SQL 没走索引。按用户聚合后排序，能快速揪出问题源头：
- 执行以下语句可列出各用户当前的逻辑读和物理读总量：
SELECT s.username, SUM(se.value) AS consistent_gets<br>FROM v$session s, v$sesstat se, v$statname n<br>WHERE s.sid = se.sid<br> AND se.statistic# = n.statistic#<br> AND n.name = 'consistent gets'<br> AND s.username IS NOT NULL<br>GROUP BY s.username<br>ORDER BY consistent_gets DESC;
- 如果某用户
physical reads占consistent gets比例 > 15%，说明其 SQL 很可能全表扫描且 buffer cache 命中率低 - 别只盯单条 SQL——一个 Java 应用用连接池连着 20 个
username='APP'的会话，加起来的读取量才是真实压力
查活跃会话正在执行什么 SQL
光看资源数字不够，得知道这些资源花在哪条语句上。用 v$session 关联 v$sql 是最快路径，但要注意匹配条件：
- 必须用
s.sql_id = q.sql_id关联，不能只靠sql_text模糊匹配（会被截断、含换行、大小写不一致） - 优先查
status = 'ACTIVE'的会话，INACTIVE会话的sql_id是上一条执行完的，不代表当前状态 - 示例：
SELECT s.sid, s.username, s.status, q.sql_text, q.buffer_gets, q.disk_reads<br>FROM v$session s, v$sql q<br>WHERE s.sql_id = q.sql_id<br> AND s.status = 'ACTIVE'<br> AND s.username IS NOT NULL<br>ORDER BY q.buffer_gets DESC<br>FETCH FIRST 5 ROWS ONLY;
真正容易被忽略的是：v$sesstat 中的资源计数不会自动清零，也不代表“此刻正在猛占资源”。它只是从会话建立以来的累计值。所以单次快照只能比相对大小，想确认是否“正在恶化”，必须连续采样并计算 delta。另外，username IS NULL 的会话（如外部认证连接）也要纳入监控范围——它们可能来自代理层，但资源消耗一样真实。
