PX Deq Credit: send blkd飙升是并行协调失衡而非资源耗尽，主因是QC处理不过来导致Slave进程排队等待发消息许可；需通过v$session定位卡住的Slave进程，检查dba_tables和dba_indexes中degree>1的对象，按对象粒度执行NOPARALLEL禁用，并警惕GV$视图、统计信息收集等隐式并行源。
为什么AWR里PX Deq Credit: send blkd突然飙升
这不是资源耗尽的信号，而是并行协调失衡的表现：QC（Query Coordinator）处理不过来，Slave进程排队等“发消息许可”。常见于本该串行的场景被意外并行化，比如INSERT INTO ... SELECT /*+ parallel */但没开PARALLEL DML，或者GV$SESSION这类视图在RAC环境下被频繁查询——它本身就会触发并行执行。
怎么快速定位是哪个对象或SQL在驱动并行
别先看AWR里的总等待时间，先查实时会话和对象级并行设置：
- 运行
SELECT sid, serial#, sql_id, event, p1, p2 FROM v$session WHERE event = 'PX Deq Credit: send blkd'，拿到p1值后用官方解码脚本查出具体是哪个Slave进程（如P012）卡住 - 查
SELECT owner, table_name, degree, instances FROM dba_tables WHERE degree > 1 OR instances > 1，重点盯degree > 1的表——很多是建表时忘了重置并行度 - 查索引：
SELECT index_name, table_name, degree FROM dba_indexes WHERE degree > 1，尤其注意那些DEGREE > 2却长期不用的索引，它们会把普通查询也拖进并行通道
如何安全关闭不必要的并行
不能一刀切禁用并行，得按对象粒度清理，否则OLAP类大查询会崩：
- 对表：用
ALTER TABLE t_name NOPARALLEL，不是DEGREE 1——后者仍可能被hint激活 - 对索引：用
ALTER INDEX i_name NOPARALLEL，比REBUILD更轻量，不锁表 - 临时禁用会话级并行：
ALTER SESSION DISABLE PARALLEL DML、ALTER SESSION DISABLE PARALLEL DDL，适合排查阶段 - 检查
parallel_degree_policy参数，设为MANUAL可防止自动并行“偷偷生效”
容易被忽略的隐式并行来源
很多PX Deq Credit: send blkd根本不是业务SQL引起的：
-
GV$系列视图（如GV$SESSION、GV$SQL）在RAC中默认并行访问，监控脚本里每5秒刷一次SELECT * FROM gv$session就足以压垮QC - 统计信息收集作业如果用了
DEGREE > 1且未清理，后续所有基于该表的查询都可能继承并行倾向 - 物化视图刷新、逻辑备库同步（如
DBMS_LOGSTDBY.START_LOGSTDBY）也可能带出隐藏并行
真正要盯的不是等待时间本身，而是谁在无意识地打开并行闸门——尤其是那些没人认领、但DEGREE设成32的索引。
