os thread startup等待事件表明并行执行在os层线程创建严重争用，根源多为索引degree>1等并行属性失控或os资源瓶颈，需优先禁用无关并行而非扩容参数。
直接查 v$active_session_history 里出现 os thread startup 等待事件，基本就能断定是并行执行在操作系统层卡住了——不是 sql 慢，而是连新线程都起不来。
查 os thread startup 对应的 SQL 和并行来源
这个等待事件本身不带 SQL_ID，但一定和某条高并发并行操作强相关。得先把它和真实 SQL 关联起来：
- 用
SQL_ID关联v$active_session_history或dba_hist_active_sess_history，过滤event = 'os thread startup'，拿到高频出现的SQL_ID - 查该
SQL_ID的执行计划：SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('56h2h7wxpnntt', NULL, 'ALLSTATS LAST'));，确认是否含PX COORDINATOR或PX SEND等并行操作符 - 重点检查该 SQL 涉及的表和索引：
SELECT owner, index_name, degree FROM dba_indexes WHERE table_name IN (/*对应表名*/);，很多问题是索引残留了degree > 1，查询时 Oracle 自动启用并行
RAC 环境下必须用 gv$active_session_history 查并行倾斜
单实例视图 v$active_session_history 在 RAC 中会漏掉跨节点的 PX 进程。真正暴露并行倾斜的是 time_waited，不是采样次数：
- 执行：
SELECT inst_id, sql_id, event, COUNT(*) cnt FROM gv$active_session_history WHERE sample_time > SYSDATE - 1/1440 AND (event LIKE 'PX %' OR event LIKE 'parallel %') GROUP BY inst_id, sql_id, event ORDER BY cnt DESC; - 若同一
sql_id在多个inst_id上都有等待，但MAX(time_waited)差异极大（比如节点 2 是 800ms，节点 1 是 5ms），就是典型的工作分配不均 -
time_waited > 5000000（即 >5 秒）是硬信号：至少有一个 PX slave 卡住，拖慢整个并行组
区分是并行度失控，还是 OS 资源真不足
os thread startup 是 OS 层线程创建争用，但背后原因分两类，处理方式完全不同：
- 如果系统 CPU 使用率低、
parallel_max_servers远未打满、v$px_process_sysstat中server highwater也没攀高，大概率是某个索引或表残留了并行属性，导致单条 SQL 意外触发高 DOP - 如果 CPU 长期 >90%、
parallel_max_servers接近上限、server highwater持续上涨，说明并行资源池被耗尽，OS 已无力响应新进程请求 - 特别注意 Solaris 系统（见 MOS Doc ID 1909881.1）：同等负载下比 Linux 更容易触发此等待，不能简单套用 Linux 经验
快速止血：禁用无关并行，别调大 parallel_max_servers
临时缓解比盲目扩容更有效。生产 OLTP 环境中，绝大多数 SQL 不该走并行——它本就不是为短事务设计的：
- 对已发现的并行索引，立即执行：
ALTER INDEX schema.idx_name NOPARALLEL;。别信“重建时没加 parallel 就安全”，degree是独立属性，可能残留 - 全局禁止自动并行（Oracle 11g+）：
ALTER SYSTEM SET parallel_degree_policy = 'MANUAL';，避免优化器自作主张 - 慎用
parallel_max_servers调大：它只延缓问题，不解决根源；且会加剧 PGA 消耗和内存竞争，可能引发PX Deq Credit: need buffer等连锁等待
真正麻烦的是那种“查不到 os thread startup，但 CPU 打满、parallel_max_servers 也满了”的情况——这时候得翻 v$px_process 和 v$px_session 看实际活跃的 PX 进程数，再结合 MODULE 和 ACTION 字段反推是谁在偷偷开并行。
