共計 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 小編會繼續努力為大家帶來更多實用的文章！
