PX 由接收 SQL 请求的主线程和查询计划中涉及的 Tablet Location Server 的 1 个或者多个线程共同执行，PX SQL 卡住可能会伴随 DDL 执行卡住 Schema Cache 长期占用不释放，租户队列积压，统计信息收集无法完成等异常。可按如下步骤排查。
PX 执行卡住问题排查
确定各物理算子是否还在执行
通过查询
Real Time Sql Plan Monitor确定算子实时吐行是否有变化，如果持续增长，表明该 SQL 仍在执行，可以根据结果显示的查询计划进一步分析性能差的原因。这个 SQL 每次查询结果获得的是当前时间点算子的吐行信息，可反复查询多次观察算子吐行是否有变化，如下图。
TRACE_ID 值可以通过命令
show full processlist或视图GV$OB_PROCESSLIST获取。关于 Sql Plan Monitor 的使用简单说明可参考 Real Time Sql Plan Monitor 使用简介 这一节。
获取各 Server 卡住线程
由于 PX 线程执行和 session 绑定，因此可以通过 session 监控查看当前执行的 PX 各个线程信息，获取执行时间 time，各 OBServer 上的线程号，如下图。
obstack/pstack 获取线程堆栈。
获取到线程号后可以看每个线程的卡住点，主线程通常是在消息循环，需要着重看各分布式子任务的堆栈有无异常，如下图。
该堆栈为主线程堆栈，可看到包含
ObWorkerProcessor::process_one关键字，如下图。
注意
obstack或者pstack在线上/业务环境均需慎重使用，使用时需和DBA沟通。线下推荐obstack，性能更好，并且可以聚合堆栈。日志获取 DTL 消息异常日志。
在前面的步骤中已经获取到 TRACE ID，并且获取到在哪些 Server 上执行，可以去这些 Server 上获取日志，为了排除 DTL 在某些关键控制消息传输上失败，需搜寻 DTL Flush 消息失败的日志，如下图。
主线程获取异常重试日志。
部分 SQL 一直处于反复重试的逻辑上，现象上表现为卡住，主线程为接收 SQL 请求的线程，SQL 级重试除 DAS 外均在主线程完成，利用重试关键字获取相关信息。
grep Y4E6A0B7C055D-0005F6B4998E148A-0-0 observer.log | grep 'check if need retry'输出结果如下图所示：
尝试获取其他异常日志。
由于 PX 执行会在多个 Server上，通过 TRACE ID 我们可以知道主线程 svr ip，svr port。
TRACE ID 转 svr_ip, svr_port
可在主线程先行搜寻日志, 如果无异常, 可搜寻所有 Server 同 TRACE ID 日志, 重点观察时间点最早的报错日志，如下图。
end ddl 报 -4023 导致 PX 执行卡住。
Real Time Sql Plan Monitor 使用简介
功能说明
此功能用于监控SQL执行算子实时执行情况。
监控场景
当 SQL 加上了 /+ monitor/ hint时, 将纳入实时监控。
当 SQL 是分布式执行且 parallel > 1 自动纳入实时监控。
普通 SQL 如果执行时间 > 5s，自动纳入实时监控。
查询方式
查询全量监控信息。
select plan_line_id, plan_operation from oceanbase.gv$sql_plan_monitor;查询实时监控信息。
select plan_line_id, plan_operation from oceanbase.gv$sql_plan_monitor where request_id < 0;查询归档监控信息。
select plan_line_id, plan_operation from oceanbase.gv$sql_plan_monitor where request_id >= 0;
适用版本
OceanBase 数据库所有版本。
