共计 4106 个字符，预计需要花费 11 分钟才能阅读完成。
这篇文章主要介绍“oracle 中 os thread startup 等待故障分析”，在日常操作中，相信很多人在 oracle 中 os thread startup 等待故障分析问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”oracle 中 os thread startup 等待故障分析”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！
这是一个原来遇到过，困扰过了我们很多人很久的故障，问题迟迟无法解决的原因是因为概念的模糊。os thread startup 是 oracle 等待事件中 Concurrency 的一个等待，与之相关的解释实际非常少。从种种故障现象及字面意义来理解，在进行并行分配是向 os 申请进程启动，而在正常的系统中，该动作是非常快的，在我们高压力的数据库环境下，os 存在响应问题，激发了该等待事件的等待。最近因整理以前知识，由此记录一下。
以下摘录于网络的解释：
Know more about “os thread startup” ‘os thread startup’ takes significant amount of time in ‘create index parallel’.
All slaves are allocated one by one in serial.
SQL tracing on foreground, there is one ‘os thread startup’ wait per slave, each wait takes 100ms. – May
need investigation
When there are 512 slaves, ‘os thread startup’ wait take 50 seconds before the slaves start to do any job.
Resolution is to set *.parallel_min_servers=512 to pre-allocated 512 slaves per instance duirng instance
startup, or to run PCIX twice and ignore the first run【故障现象】
1. 数据库出现 os thread startup 等待，并伴随着大量 DFS lock handle,log file sync，latch free 等等待堆积。
2. 首先出现异常等待节点数据库阻塞达到一定程度，系统资源大量消耗，主机 hang 住。
3. 另外一节点数据库受前一节点数据库影响出现大量 gc 等待事件，但异常等待积累到一定程度便出现 DFS lock handle 等等待，系统资源大量消耗，主机 hang 住。
【分析处理思路】
1. 数据库等待情况：
从 dba_hist_active_sess_history 分析，数据库出现 os thread startup，之后开始引起大量的 log file sync，latch free 等待和 DFS lock handle 等阻塞。并且阻塞的源头是 os thread startup.
节选：
节点 1 根据时间点，按等待事件进行汇总：
28-JUL-16 04.22.16.187 PM PX Deq: Slave Session Stats 1
28-JUL-16 04.22.16.187 PM control file sequential read 1
28-JUL-16 04.22.16.187 PM
os thread startup
1 —
28-JUL-16 04.22.16.187 PM gc current grant 2-way 2
28-JUL-16 04.22.16.187 PM ASM file metadata operation 2
……
28-JUL-16 04.22.16.187 PM gc buffer busy release 11
28-JUL-16 04.22.16.187 PM db file sequential read 54
28-JUL-16 04.22.16.187 PM 107
28-JUL-16 04.22.16.187 PM log file sync 114 —-
28-JUL-16 04.22.16.187 PM latch free 138 —-
28-JUL-16 04.22.27.538 PM gc cr grant 2-way 1
2.LGWR trace 写入出现告警，实际写入的数据量非常小，却消耗了大量的时间。
### LGWR trace 日志 ###
LGWR 写入量及其耗用的时间，直观表明 I / O 出现写入缓慢的情况
*** 2016-06-21 17:11:22.234
Warning: log write elapsed time 516ms, size 16727KB
*** 2016-06-21 17:11:44.492
Warning: log write elapsed time 21902ms, size 16KB
*** 2016-06-21 17:12:08.449
Warning: log write elapsed time 23529ms, size 381KB
3.CPU 使用情况
（1）故障前主机 CPU 资源耗尽并存在多个 CPU 分区负荷 100% 的情况，另外存在多个 CPU 分区高负荷并且是系统 SYS 占用
（2）ORACLE
SR 分析并结合其接触过的案例，AIX 下可能存在 CPU 折叠的情况，单个 CPU 满负荷使用会造成无法调度，而造成 OS hang 或非常缓慢的情况后 IBM 已解释并说明目前系统的 CPU 不会出现 CPU 折叠的情况，相关系统参数已设置正确，
vmstat：
zzz ***Thu Jul 28 09:37:45 BEIST 2016 —CPU 资源 IDLE 30% 左右
System configuration: lcpu=256 mem=745216MB
kthr memory page faults cpu
—– ———– ———————— ———— ———–
r b avm fre re pi po fr sr cy in sy cs us sy id wa
100 0 134703580 35782109 0 0 0 0 0 0 25724 255043 108481 61 12 22 5
86 0 134705919 35779762 0 0 0 0 0 0 21259 215539 88214 57 9 28 6
77 0 134701214 35784474 0 0 0 0 0 0 18884 194253 76418 54 9 30 7
zzz ***Thu Jul 28 09:38:41 BEIST 2016 —CPU 资源耗尽
System configuration: lcpu=256 mem=745216MB
kthr memory page faults cpu
—– ———– ———————— ———— ———–
r b avm fre re pi po fr sr cy in sy cs us sy id wa
272 1 134995188 35752075 0 0 0 0 0 0 4881 231230 79391 81 13 3 3
253 0 134995238 35752029 0 0 0 0 0 0 3699 179424 63599 79 13 4 3
203 1 134997247 35750015 0 0 0 0 0 0 4928 258230 62545 75 14 7 5
mpstat：
zzz ***Thu Jul 28 09:36:59 BEIST 2016
System configuration: lcpu=256 mode=Capped
cpu min maj mpc int cs ics rq mig lpa sysc us sy wa id pc
….
84 581 0 0 499 1298 239 1 386 100 4098 74 15 2 9 0.30
85 0 0 0 236 21 21 1 0 100 0 99 1 0 0 0.55 —cpu 100%
4. 磁盘 IO 情况
故障期间 redo
file 所在磁盘组 DGSYSDG 对应的所有磁盘都存在一个共同的现象，磁盘的 MAXSERV 的值开始出现异常上涨，maxserv 从 20 以下上涨至 100~400 左右，maxserv 异常增长与 log file sync 异常增长的时间点非常吻合，并且峰值的时间点一致。
5. 磁盘 maxserv 与数据库 log file sync 对比数据
发现故障前 log file sync 高且 redo 所在磁盘的 maxserv 高的异常表现，后与 IBM 同事通过部署脚本实时对新划的一块磁盘进行数据持续写入并抓取出磁盘的 maxserv 数据，后对比新划磁盘的 maxserv 峰值与 redo 所有磁盘的 maxserv 峰值出现时间，得出两者峰值出现时间点一致
6. 其他
（1）通过部署 truss、pdump 脚本对故障前夕出现异常等待事件 os thread startup 进程的捕获跟踪，并同时触发运行 trace 脚本
（2）通过 pau 数据去了解磁盘读写响应时间，可以了解磁盘方面读写是否存在性能问题
【原因 解决办法】确认 maxserv 是导致故障的直接原因
1. 因为受 maxserv 高的影响，每次故障都导致大量的 log file sync 的等待，从而导致应用大量的积压。
2. 仅仅是 maxserv 高不一定会引起故障，每次故障前还伴随着数据库二阶段应用量增大；
因此，引发故障需要具备两个条件：1. 磁盘 maxserv 高 2. 二阶段应用量出现高峰，故障基本出现在业务高峰期间。
最后的解决方法是通过更换了性能更好的 e880 主机后再无出现此故障。
到此，关于“oracle 中 os thread startup 等待故障分析”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！
