面试宝典:Oracle数据库cell list of blocks read request等待事件处理过程

最新推荐文章于 2025-11-24 15:52:13 发布

原创最新推荐文章于 2025-11-24 15:52:13 发布 · 684 阅读

19 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #面试 #oracle

AI辅助_面试宝典专栏收录该内容

584 篇文章

订阅专栏

在这里插入图片描述

Oracle 数据库 “cell list of blocks read request” 等待事件深度解析

一、事件本质与原理

核心定义

“cell list of blocks read request” 是 Exadata特有的等待事件，发生在数据库向存储节点（Cell Server）发起块列表读取请求后，等待存储节点响应的阶段。此事件表征存储节点处理请求的延迟，与后续实际的物理读取操作（cell list of blocks physical read）分离。

工作原理

关键特性

请求-响应分离：分两个独立事件（请求等待 + 物理读取）
纯等待阶段：不包含实际I/O时间，仅衡量请求处理延迟
存储节点资源敏感：直接反映存储节点的处理能力
Exadata专用：仅出现在Exadata存储架构中

二、产生过程与典型场景

1. 请求生命周期

请求生成：DB节点编译需读取的块列表（如索引扫描后）
请求发送：通过InfiniBand网络发送到存储节点
存储节点接收：Cell Server接收请求并放入队列
等待资源：存储节点分配CPU/内存等资源
就绪响应：存储节点返回"请求已接受"信号
物理读取：触发cell list of blocks physical read

2. 典型高发场景

场景	触发条件	风险等级
存储节点CPU过载	多DB节点并发请求同一存储节点	高
InfiniBand网络拥堵	跨机架大量数据传输	中
存储节点内存压力	Flash Cache频繁换出	中
I/O请求队列积压	突发高并发索引扫描	高

三、根本原因分析

1. 存储节点资源瓶颈

资源类型	检测命令/指标	临界值
CPU	`CellCLI> LIST METRICCURRENT WHERE name = 'CD_IO_UTIL'`	> 90%
内存	`CellCLI> LIST METRICCURRENT WHERE name = 'MEMORY_FREE'`	< 10% of total
请求队列	`v$cell_workload` 中 `avg_workload`	> 5

2. 网络层问题

# 检测InfiniBand问题
ibcheckerrors -v  # 错误包统计
ibqueryerrors     # 实时错误监控

# 关键指标：
- 重传率：`iblinkinfo -R` > 3%
- 带宽利用率：`ibstatus` > 80%

3. 数据库行为问题

索引风暴：

SELECT sql_id, executions, disk_reads 
FROM v$sql 
WHERE disk_reads/executions > 10000; -- 单SQL超高离散读

低效批处理：

-- 每次请求块数过少（<10）
SELECT AVG(p3) FROM v$active_session_history 
WHERE event = 'cell list of blocks read request'

四、详细排查流程

步骤1：事件特征分析

-- 检查事件详情
SELECT sid, seq#, p1, p2, p3, 
       p1text, p2text, p3text 
FROM v$session_wait 
WHERE event = 'cell list of blocks read request';

/* P参数解析：
   P1: 请求的块数
   P2: 存储节点索引号
   P3: 请求队列深度 */

步骤2：存储节点诊断

-- 定位高负载存储节点
SELECT cell_path, 
       SUM(wait_time) total_wait_ms,
       AVG(wait_time) avg_wait_ms
FROM v$cell_state
WHERE wait_reason = 'cell list of blocks read request'
GROUP BY cell_path
HAVING AVG(wait_time) > 1; -- >1ms为异常

步骤3：关联SQL分析

-- 查找触发事件的热点SQL
SELECT s.sql_id, s.con_id, p.pdb_name,
       COUNT(*) waits,
       SUM(w.time_waited) total_wait_us
FROM v$active_session_history w
JOIN v$session s ON w.session_id = s.sid
JOIN v$pdbs p ON s.con_id = p.con_id
WHERE w.event = 'cell list of blocks read request'
GROUP BY s.sql_id, s.con_id, p.pdb_name
ORDER BY total_wait_us DESC;

步骤4：存储节点资源检查

# CellCLI 实时监控
CellCLI> LIST METRICCURRENT ATTRIBUTES name,metricValue \
         WHERE name IN ('CD_IO_UTIL','MEMORY_FREE','IB_NETWORK_RETRANSMITS')

# ExaWatcher 历史分析
exawatcher --show_all --last 30  # 过去30分钟数据

五、优化方案

1. 存储节点优化

# 动态调整资源分配
CellCLI> ALTER IORMPLAN db_plan = (                     \
           dbplan: (                                    \
             name=prod_db, level=1, allocation=80,      \
             flashcache=on, flashlog=on)                \
         )

# 扩容闪存缓存（需停机）
CellCLI> ALTER FLASHCACHE ALL SIZE = 2T

2. 网络优化

# 调整InfiniBand QoS
mlnx_qos -i ib0 --trust dscp    # 启用DSCP优先级
mlnx_qos -i ib0 --pfc 0,0,0,1,0,0,0,0  # 为RDMA流量启用PFC

# 优化MTU（巨型帧）
ifconfig ib0 mtu 65520

3. 数据库优化

-- 增加批量请求大小
ALTER SESSION SET "_kcfis_read_batch_count" = 256;  -- 默认128

-- SQL重写（减少离散读）
/* 低效写法 */
SELECT * FROM orders WHERE order_id IN (SELECT order_id FROM temp_ids);

/* 高效写法 */
SELECT /*+ HASH_SJ */ o.* 
FROM orders o JOIN temp_ids t ON o.order_id = t.order_id;

4. 对象优化

-- 重建高离散表
ALTER TABLE sales MOVE PARTITION sales_q1 COMPRESS FOR QUERY HIGH;

-- 创建反向键索引
CREATE INDEX idx_sales_id ON sales(sale_id) REVERSE;

六、深度诊断工具

1. 请求链路跟踪

-- 启用Cell跟踪
ALTER SYSTEM SET EVENTS 'trace[cell_client.*] disk=high';

/* 关键日志位置：
   /var/log/oracle/cell/logs/celltrace/cellserv_*/celltrace.trc
*/

2. 请求时序分析

SELECT * FROM TABLE(DBMS_WORKLOAD_REPOSITORY.AWR_WAIT_CHAIN_REPORT(
  begin_snap => &begin_snap,
  end_snap   => &end_snap));

3. 网络抓包分析

# 捕获RDMA流量
tcpdump -i ib0 -s 0 -w cell_traffic.pcap 'port 7777'  # Exadata默认端口

# 使用Wireshark分析：
- 过滤条件：infiniband.dlid == <目标LID>
- 关键指标：RTT（请求到响应时间）

七、优化效果评估矩阵

优化措施	预期延迟下降	验证方法
存储节点CPU扩容	50%-70%	`v$cell_state.cpu_utilization`
IB网络QoS调整	30%-50%	`ibnetdiscover -s` 错误包统计
批量请求参数调整	20%-40%	`v$sesstat._kcfis_read_batch_count`
表重组+压缩	40%-60%	`dba_tables.chain_cnt` 减少量

黄金诊断法则：

延迟阈值：>1ms即需干预（Exadata正常值<0.5ms）
根因定位三步法：
查存储节点资源（CellCLI> LIST METRICCURRENT）
验网络健康度（ibstatus）
析请求模式（v$session.p3队列深度）

优化优先级：
网络 > 存储节点配置 > 数据库参数 > SQL优化
当此等待占DB时间>2%时，必须启动存储层深度优化。