os thread startup等待事件表明os层线程创建严重争用，根源多为并行度失控（如索引degree>1）或os资源瓶颈，需优先禁用无关并行而非扩容参数。
os thread startup 出现在 ash 报告里，基本可以断定是并行执行在操作系统层遇到了资源瓶颈——不是 sql 写得慢，而是连新线程都起不来。这通常意味着数据库正试图启动大量并行从进程（px slaves），但 os 调度已严重争用，甚至开始拒绝创建新线程。
查 os thread startup 对应的 SQL 和并行来源
这个等待事件本身不直接告诉你哪条 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 自动启用并行
区分真实瓶颈：是并行度失控，还是 OS 资源不足
os thread startup 是个 Concurrency 类等待，本质是 OS 层进程/线程创建变慢。但背后原因分两类：
- 如果数据库整体负载不高（CPU 使用率 parallel_max_servers 远未打满），那大概率是某个对象（如索引）残留了并行属性，导致单条 SQL 意外触发高 DOP（Degree of Parallelism）
- 如果系统 CPU 长期 > 90%、
parallel_max_servers接近上限、v$px_process_sysstat中server highwater持续攀高，说明是并行资源池被耗尽，OS 已无力响应新进程请求 - 特别注意 Solaris 系统（见 MOS Doc ID 1909881.1）：该平台对线程创建更敏感，同等负载下比 Linux 更容易触发此等待
快速止血：禁用无关并行，而非调大参数
临时缓解比盲目扩容更有效。生产 OLTP 环境中，绝大多数 SQL 不该走并行——它本就不是为短事务设计的。
- 对已发现的并行索引，立即执行：
ALTER INDEX owner.index_name NOPARALLEL;，别信“重建时没加 parallel 就安全”，DEGREE是独立属性，可能残留 - 全局禁止自动并行（Oracle 11g+）：
ALTER SYSTEM SET parallel_degree_policy = 'MANUAL';，避免优化器自作主张 - 慎用
parallel_max_servers调大：它只延缓问题，不解决根源；且会加剧 PGA 消耗和内存竞争，可能引发PX Deq Credit: need buffer等连锁等待
验证并行是否真被关闭
改完不能只看 DDL 成功，要确认运行时行为已改变：
- 再次执行原 SQL，查
v$sql：SELECT sql_id, degree_level, parallel_executions_started FROM v$sql WHERE sql_id = '56h2h7wxpnntt';，degree_level应为 1，parallel_executions_started应为 0 - 观察 ASH 中该 SQL 后续采样：等待事件应从
os thread startup/PX Deq: Execute Reply切换为常规 I/O 或 CPU 等待 - 注意：即使索引已
noparallel，若 SQL 中显式写了/*+ PARALLEL(t,4) */，仍会走并行——得同步清理应用层 hint
真正卡顿的根源往往不在数据库内部调度逻辑，而在「不该并行的地方开了并行」。一旦 os thread startup 频繁出现，优先排查对象级并行残留，而不是调优 SQL 或升级硬件。
