V$SESSION_LONGOPS是查索引重建进度的唯一可靠入口，ASH因仅采样前台会话、忽略后台进程协同开销且不聚合分散事件，无法反映真实资源消耗。
v$session_longops 是查进度的唯一可靠入口，ash 本身不记录索引重建的资源消耗细节——它既不捕获 alter index ... rebuild online 的 cpu/pga/io 分布，也不暴露重建过程中后台进程（如 ora<em>d000</em><em></em>、ora<em>lgwr</em>）的协同开销。
为什么直接查 ASH 看不到在线重建的真实负载？
在线索引重建是典型的“前台发起、后台执行”模式：ALTER INDEX ... REBUILD ONLINE 语句本身几乎不等待，很快返回；真正干活的是多个后台进程（如 ora_d000_* 做 DML 重放、ora_lgwr_* 刷日志、ora_dbw0_* 写数据块），而 ASH 默认只采样前台会话状态，且采样间隔 1 秒，极易错过短时高负载片段。
更关键的是：重建过程中的逻辑读、UNDO 生成、日志写入、临时段分配等行为，分散在不同事件和进程里，ASH 不做聚合，也不关联后台链路。你看到的 sql_id 往往是递归 SQL（如 INSERT /*+ APPEND */ 或 UPDATE），而非原始 REBUILD 语句。
-
EVENT列可能出现db file sequential read（读源索引）、log file sync（提交 DML）、direct path write temp（排序溢出），但无法区分哪些属于重建，哪些是并发业务 -
session_state = 'ON CPU'样本若集中在sql_id为0000000000000000，大概率是后台进程硬解析或未缓存 SQL，不是前台语句 -
MODULE和ACTION字段通常为空或继承自客户端（如sqlplus.exe），除非应用显式调用DBMS_APPLICATION_INFO.SET_MODULE
怎样用 ASH 辅助定位重建期间的异常争用？
ASH 不适合看“重建花了多少资源”，但能帮你发现“重建引发了什么副作用”。重点盯住三类信号：
- 查
enq: TX - row lock contention或enq: TM - contention：说明重建期间 DML 被阻塞，尤其是ONLINE模式下锁升级或 ITL 不足 - 查
log file sync等待突增：结合v$session_event确认是否因重建触发大量小事务提交（如每 1000 行 commit 一次） - 查
db file sequential read+ 高pga_allocated组合：可能对应索引扫描 + 排序阶段，此时应关联SQL_ID查V$SQL_WORKAREA_ACTIVE确认是否 PGA 溢出
示例（查最近 10 分钟内重建引发的锁争用）：
SELECT sample_time, event, p1text, p1, p2text, p2, session_id, sql_id
FROM v$active_session_history
WHERE event IN ('enq: TX - row lock contention', 'enq: TM - contention')
AND sample_time > SYSDATE - 10/1440
ORDER BY sample_time DESC;真正监控重建进度和资源，该查哪几个视图？
别在 ASH 里硬找，直接切到专有视图：
-
V$SESSION_LONGOPS：唯一能查到重建实时进度的地方。过滤opname LIKE '%INDEX%'且sofar < totalwork，time_remaining字段虽是估算，但比猜准得多 -
V$TEMPSEG_USAGE：查当前临时段使用量。重建走排序路径时会分配临时空间，ALLOCATED_SPACE突增可佐证排序开销 -
V$SQL+SQL_ID关联：从V$SESSION_LONGOPS拿到sql_id后，查V$SQL的buffer_gets、cpu_time、elapsed_time，注意child_number = 0才是主执行计划 -
V$PGASTAT和V$SQL_WORKAREA_ACTIVE：确认是否 PGA 不足导致频繁写临时段——cache_hit_percentage低于 70% 或V$SQL_WORKAREA_ACTIVE中onepass_executions/multipass_executions比例升高，都是信号
重建期间最易被忽略的性能陷阱
在线重建不是“不锁表就无代价”。容易被漏掉的点包括：
- 日志生成速率翻倍：查
v$log_history每分钟归档量，若重建期间突增 3–5 倍，说明 UNDO + REDO 写放大严重，可能拖慢其他事务 - 索引统计信息失效：重建后
LAST_ANALYZED不自动更新，后续执行计划可能退化，必须手动DBMS_STATS.GATHER_INDEX_STATS - 局部索引分区未同步：对分区表执行
ALTER INDEX ... REBUILD ONLINE时，若没指定PARTITION，默认只重建全局索引；局部索引需单独处理，否则查询分区裁剪失效 -
_sort_multiblock_read_count隐含参数影响：该值过低会导致排序阶段多次读取同一块，ASH 中表现为高频db file sequential read，但event本身不提示根源
