這篇文章主要介紹“oracle中os thread startup等待故障分析”，在日常操作中，相信很多人在oracle中os thread startup等待故障分析問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”oracle中os thread startup等待故障分析”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
這是一個原來遇到過，困擾過了我們很多人很久的故障，問題遲遲無法解決的原因是因為概念的模糊。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等待故障分析”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
