面试宝典:介绍下Oracle数据库动态性能视图 V$PQ

在这里插入图片描述
好的，我们来对 Oracle 19C 数据库中的 V$PQ_TQSTAT 动态性能视图进行一次极其详细和准确的解析。这个视图是诊断和优化 Oracle 并行查询（Parallel Query, PQ）性能的终极武器，它提供了并行执行过程中最精细粒度的洞察。

1. 作用与概述

V$PQ_TQSTAT 视图的主要作用是提供刚刚执行完毕的并行查询操作中，每个表队列（Table Queue, TQ）的详细运行时统计信息。它揭示了数据在并行服务器进程间流动的细节，是诊断并行执行性能问题（尤其是数据倾斜和执行倾斜）的最重要工具。

核心概念：表队列（Table Queue, TQ）
在并行执行中，数据在不同的生产者（Producer）和消费者（Consumer）进程组之间流动。这个流动的通道就是表队列。例如，一组进程并行扫描一个表（生产者），将数据通过一个 TQ 发送给另一组进程进行并行连接或排序（消费者）。V$PQ_TQSTAT 展示了每个这样的通道上发生了什么。

简而言之，它回答了 DBA 最关心的问题：“我的并行查询在‘流水线’的每一步中，数据分配是否均匀？有没有哪个环节成了瓶颈？”

2. 使用场景

诊断并行执行倾斜（Data Skew）：
这是其首要用途。如果查询性能不佳，通过此视图可以精确判断是哪些并行服务器进程处理了过多的数据，导致负载不均，从而定位到SQL或数据层面的问题。
验证并行执行计划：
通过观察 TQ 的数量和数据流，可以验证实际的执行计划是否与预期一致，例如，确认是否真的发生了并行操作以及操作是如何分阶段的。
识别并行执行瓶颈：
分析生产者和消费者的速度。如果生产者很快但消费者很慢，或者反之，可以判断出瓶颈是在数据分发阶段还是在数据处理阶段。
量化并行操作成本：
了解每个并行步骤处理的数据量（行数、字节数），这对于SQL调优和优化器成本估算非常有价值。

3. 字段含义详解

V$PQ_TQSTAT 必须在执行完一个并行查询后，立即在同一个会话中查询才能看到该查询的统计信息。它的内容会在下一个语句执行时被重置。

以下是 V$PQ_TQSTAT 视图中每个字段的精确说明。

字段名	数据类型	含义说明
DFO_NUMBER	NUMBER	数据流操作（Data Flow Object, DFO）树的编号。一个复杂的并行查询可能由多个 DFO 树组成。
TQ_ID	NUMBER	表队列（Table Queue）的标识符。它与执行计划中的 `PX SEND` 和 `PX RECEIVE` 操作符的 `TQ` 列值相对应。
SERVER_TYPE	VARCHAR2(10)	进程在表队列中的角色。这是最关键的字段之一。 - `Producer`: 向该表队列发送数据的并行服务器进程。 - `Consumer`: 从该表队列接收数据的并行服务器进程。 - `Ranger`: 负责分配工作单元（如范围granules）的协调者进程。
NUM_ROWS	NUMBER	该进程在此表队列中处理的行数。用于诊断数据倾斜的核心字段。
BYTES	NUMBER	该进程在此表队列中处理的字节数。
OPEN_TIME	NUMBER	打开表队列所花费的时间（单位：百分之一秒）。
AVG_LATENCY	NUMBER	消息在该表队列中的平均延迟（单位：百分之一秒）。
WAITS	NUMBER	该进程在此表队列上等待的次数。
TIMEOUTS	NUMBER	该进程在此表队列上等待超时的次数。
PROCESS	VARCHAR2(7)	进程的名称/标识符（如 `P002`）。对于 `Producer`/`Consumer`，这是并行服务器进程名；对于 `Ranger`，这是查询协调器（QC）进程。
INSTANCE	NUMBER	在 Oracle RAC 环境中，该进程所在实例的标识符。
CON_ID	NUMBER	包含此统计信息的容器的 ID。在 CDB 环境中，指示该操作发生在哪个 PDB。

4. 相关视图与基表

相关动态性能视图：
- V$PQ_SLAVE：提供并行服务器进程的实时状态和累计工作量。V$PQ_TQSTAT 是其针对上一次操作的分解。
- GV$PX_SESSION：显示并行执行会话的关联关系，帮助理解 Producer 和 Consumer 是如何分组的。
- V$SQL_PLAN：这是最关键的关联视图。V$PQ_TQSTAT.TQ_ID 必须与 V$SQL_PLAN 中 PX SEND 和 PX RECEIVE 操作符的 TQ 列关联，才能将统计数据映射到执行计划的具体步骤。查询的 SQL_ID 可以从 V$SESSION.PREV_SQL_ID 获取。
底层基表与原理：
V$PQ_TQSTAT 是一个极为特殊的动态性能视图。
- 数据源：其数据由刚刚执行完毕的并行查询的查询协调器（QC）进程在PGA中动态生成和填充。它是一次性且瞬态的。
- 生命周期：其内容仅对当前会话有效，并且只保留最后一条执行的SQL语句的并行执行信息。执行任何新语句（甚至是简单查询）都会立即重置该视图的内容。
- 持久化：此视图中的数据绝对是非持久化的。它纯粹用于即时诊断。AWR报告中的“Parallel Execution”部分会包含类似的聚合后信息，但绝非此视图的原始明细数据。
- 底层结构：其底层来源于内部的 X$ 表（如 X$KXFPQSTAT），该表在QC进程完成并行操作后短暂地被填充。

5. 详细原理与知识点

1. 生产者-消费者模型与数据流：
Oracle 并行执行完全基于此模型。一个DFO树包含一组 Producer 进程和一个 Consumer 进程组，通过TQ连接。

例1：并行全表扫描 -> 并行排序
- 扫描进程是 Producer，发送数据到TQ。
- 排序进程是 Consumer，从TQ接收数据。
例2：并行哈希连接
- 构建表的扫描进程是 Producer，发送数据到构建端TQ。
- 探测表的扫描进程是 Producer，发送数据到探测端TQ。
- 连接进程是 Consumer，从两个TQ接收数据。

2. 诊断数据倾斜（Skew）的黄金法则：
在一个TQ中，所有相同 SERVER_TYPE 的进程（即所有Producers或所有Consumers）的 NUM_ROWS 和 BYTES 值应该大致相等。

生产者倾斜：如果某个 Producer 的 NUM_ROWS 远高于其他 Producer，说明它处理了更多的数据块。这通常是由于：
- 数据分布倾斜：例如，表的一个分区非常大，而该分区恰好被分配给一个Producer处理。
- 粒度不均：范围颗粒（Range Granules）划分不均匀。
消费者倾斜：如果某个 Consumer 的 NUM_ROWS 远高于其他 Consumer，这通常更严重，表明数据在分发过程中发生了倾斜。这可能是由于：
- 哈希分布键选择不当：例如，对一个具有重复值的列进行HASH分布，导致所有相同值的数据都发送给同一个Consumer进程。
- 广播（Broadcast）：一个小表被广播给所有Consumer，这本身是一种“倾斜”，但是预期的。

3. 执行计划关联：
没有执行计划，V$PQ_TQSTAT 的数据就失去了大部分意义。必须将 TQ_ID 与执行计划中的 PX SEND 和 PX RECEIVE 操作符关联起来，才能知道每个TQ对应的是执行计划的哪一部分操作。

6. 常用查询SQL

1. 诊断上一次并行操作的数据倾斜（核心中的核心）

SELECT dfo_number, tq_id, server_type, process, instance,
       num_rows,
       bytes,
       ROUND(bytes / NULLIF(num_rows, 0), 2) AS avg_row_size,
       -- 计算每个进程的行数相对于该TQ内同角色进程平均值的百分比
       ROUND( num_rows * 100 / NULLIF( AVG(num_rows) OVER (PARTITION BY dfo_number, tq_id, server_type), 0 ), 2 ) AS pct_of_avg
FROM v$pq_tqstat
ORDER BY dfo_number, tq_id, server_type, num_rows DESC;
-- 重点观察 pct_of_avg 远大于100%的进程，那就是倾斜点。

2. 结合执行计划进行深度分析（获取SQL_ID和Plan）

-- 步骤 1: 获取刚刚执行完的并行查询的SQL_ID
SELECT prev_sql_id
FROM v$session
WHERE sid = USERENV('SID');

-- 步骤 2: 使用上述SQL_ID查询执行计划，重点关注TQ列
SELECT *
FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('&prev_sql_id', NULL, 'ALLSTATS LAST'));

-- 步骤 3: 将V$PQ_TQSTAT与执行计划关联分析
-- 手动对比V$PQ_TQSTAT.TQ_ID和执行计划中的TQ列，理解每个数据流的意义。

3. 查看特定DFO和TQ的详细信息

SELECT *
FROM v$pq_tqstat
WHERE dfo_number = 1
  AND tq_id = 0
ORDER BY server_type DESC, num_rows DESC; -- Producer first, then Consumer

4. 检查等待和延迟情况（判断通信是否成为瓶颈）

SELECT dfo_number, tq_id, server_type, process,
       waits,
       timeouts,
       avg_latency
FROM v$pq_tqstat
WHERE waits > 0 OR avg_latency > 0
ORDER BY avg_latency DESC;