awr中识别大对象（lob）io压力需重点关注direct path read/write而非physical reads总数：若其在top 5 timed events中排名前三且av rd/wr(ms)>15ms，结合tablespace io stats中lob表空间延迟偏高、sql含dbms_lob关键字，即可确认lob为瓶颈源；lob走直接路径，不参与buffer hit%计算，且其iops统计受chunk大小影响易误判，定位须查执行计划中lobsegment/lobindex对象及v$active_session_history中file#/block#。
怎么看awr里大对象的io压力
别只盯着“physical reads”总数——大对象（lob）读写会分散在多个等待事件里，db file sequential read和db file scattered read可能都偏低，但direct path read或direct path write突然飙升才是关键信号。在awr的「top 5 timed events」里，如果这两项排进前三，且平均等待时间（av rd(ms)/av wr(ms)）超过15ms，基本可断定lob操作正在拖慢整体io。
进一步确认：去「Tablespace IO Stats」节，找到LOB所在表空间（通常是USERS或自定义的LOB_TBS），看其Av Rd(ms)是否显著高于其他表空间；再查「SQL ordered by Physical Reads」，过滤出含DBMS_LOB、READ、WRITE关键字的SQL，它们大概率就是瓶颈源头。
- 注意：LOB的物理读不等于普通表的buffer gets，它走的是直接路径，不会计入
buffer hit%计算，所以命中率指标对LOB完全失真 - 若
direct path read等待高但Physical Reads总量不高，说明是单次大块读（如读取4MB CLOB），需检查应用是否做了不必要的全LOB加载 - RAC环境下还要看「Global Cache and Enqueue Statistics」里的
gc cr block busy——LOB索引块争用也会引发GC延迟，尤其当多个节点并发读同一LOB段时
LOB字段类型和存储参数怎么影响AWR指标
AWR里看到的IO模式，直接由LOB字段定义和STORAGE参数决定。比如BLOB默认ENABLE STORAGE IN ROW，小数据存行内，AWR里就体现为普通逻辑读；一旦超4000字节转为行外存储，立刻触发direct path read，且每次读都带额外元数据访问（LOBINDEX块）。
关键参数差异：
-
CHUNK大小：默认8KB，但AWR中direct path read的IOPS统计基于OS块（通常8KB），若实际读取1MB LOB，AWR会记为128次direct path read，而非1次——这会误导你认为IOPS过高 -
PCTVERSIONvsRETENTION：前者导致旧版本LOB数据滞留，占用额外空间和IO；后者启用后，AWR的undo segment tx slot等待可能上升，间接拖慢LOB写入 -
NOLOGGING对AWR无直接影响，但会降低redo size per second，若该值在问题时段异常下降，而direct path write同步升高，可能是批量LOB插入启用了NOLOGGING，需确认归档风险
从AWR定位具体哪个LOB段在拖慢系统
光知道“LOB慢”没用，得锁定物理段。在「SQL ordered by Physical Reads」里找到高读SQL后，用它的sql_id查执行计划：DBMS_XPLAN.DISPLAY_AWR('<sql_id>', NULL, 'ALLSTATS LAST')</sql_id>，重点看OBJECT_NAME列是否指向LOBSEG$或LOBINDEX——这才是真实LOB段名，不是原表名。
反查对象位置：
- 从
v$active_session_history提取p1(file#)和p2(block#)，注意direct path read的p1是file#，p2是first block#（不是单块） - 执行：
SELECT owner, segment_name, segment_type FROM dba_extents WHERE file_id = &file_id AND &block_id BETWEEN block_id AND block_id + blocks - 1;
结果若segment_type为LOBSEGMENT或LOBINDEX，就坐实了 - 常见陷阱：分区LOB表的
segment_name只显示主表名，必须加partition_name字段才能准确定位——漏掉这点，可能优化错分区
调整哪些参数能快速缓解LOB性能问题
LOB优化不是调db_cache_size就能解决的，核心在三点：
- 增大
large_pool_size：LOB操作依赖large pool做缓冲，若free memory在AWR的「Memory Statistics」里持续低于10MB，direct path read等待必然升高；建议设为sga_target的10%~15% - 禁用
filesystemio_options = SETALL（Linux/Unix）：这个参数会让Oracle绕过OS缓存直写磁盘，对LOB写入反而增加延迟；改成ASYNCH或None更稳 - 对频繁读的LOB列建函数索引：
CREATE INDEX idx_lob_hash ON t1 (UTL_RAW.CAST_TO_RAW(lob_col))，AWR里SQL ordered by Gets会明显下降——但注意这仅适用于只读场景，写入时索引维护开销会反升
最后提醒：LOB性能问题往往藏在应用层。AWR里Executions per Sec高的LOB SQL，90%以上是应用代码把整个LOB字段SELECT出来却只用前100字节——这种浪费在报告里体现为极高的direct path read次数，但根本解法是改代码用DBMS_LOB.SUBSTR按需截取。
