動(dòng)態(tài)增加CPU帶來的數(shù)據(jù)庫重啟風(fēng)險(xiǎn)--技術(shù)人生系列第四十六期-我和數(shù)據(jù)中心的故事

周六，正是某個(gè)客戶的投產(chǎn)日，投產(chǎn)時(shí)間為晚間19:30開始，持續(xù)到翌日早上九點(diǎn)，老K負(fù)責(zé)現(xiàn)場(chǎng)支持任務(wù)。

投產(chǎn)系統(tǒng)多，七點(diǎn)半剛過，各種咨詢接踵而至，老K正忙的不亦樂乎，電話過來了：“老K，快來這邊幫幫忙看下，應(yīng)用維護(hù)團(tuán)隊(duì)說投產(chǎn)動(dòng)作比較慢，看看有沒有什么辦法加快下速度？”類似的電話接了不少，問題總要一個(gè)一個(gè)處理，但是剛剛電話涉及的系統(tǒng)還是比較重要的系統(tǒng)，投產(chǎn)窗口有限，肯定是需要更重視一些，于是答應(yīng)處理完手邊的這個(gè)問題緊接著下一個(gè)去看看這個(gè)系統(tǒng)；

但是，幾分鐘后電話再次響起：“老K，不好了，這個(gè)系統(tǒng)數(shù)據(jù)庫重啟了！快來看看吧！” 這就尷尬了，難道是因?yàn)槲覜]有及時(shí)響應(yīng)他們的問題，系統(tǒng)就撐不住重啟了？如果真是這樣，那這罪過可就大了！趕緊去到事故現(xiàn)場(chǎng)來處理這個(gè)問題。

問題現(xiàn)場(chǎng)，各路同事都在討論著這事。 這個(gè) 系統(tǒng)是一套兩節(jié)點(diǎn)的 RAC 數(shù)據(jù)庫，數(shù)據(jù)庫版本為 11g ，這次重啟實(shí)際上是數(shù)據(jù)庫兩個(gè)節(jié)點(diǎn)的實(shí)例都發(fā)生了重啟；

首先看看 alert 日志里有沒有什么信息顯示：

很顯然，數(shù)據(jù)庫在 19:41 時(shí)被 ASMB 進(jìn)程給終止了，在終止前產(chǎn)生了一些 trace 文件； ASMB 進(jìn)程是什么進(jìn)程呢？顧名思義， ASMB 進(jìn)程就是數(shù)據(jù)庫實(shí)例與 ASM 實(shí)例進(jìn)行交互的進(jìn)程，從這里的報(bào)錯(cuò)也可以到， ASMB 已經(jīng)無法連接到 ASM 實(shí)例了；

一般來說，出現(xiàn)這種情況，通常的可能是 CRS 發(fā)生了重啟，然后這里我們通過 ps –ef 查看 CRS 關(guān)鍵進(jìn)程發(fā)現(xiàn)并未發(fā)生過重啟；這樣看來與 ASM 有關(guān)；于是我們?cè)倏? ASM 的 alert 日志，關(guān)鍵部分如下 ：

可以看到 ASM 實(shí)例發(fā)生了重啟，而重啟的原因則是：

參數(shù) parallel_max_servers 被設(shè)置為 4505 ，而這個(gè)參數(shù)值是不合法的，該值的設(shè)定范圍應(yīng)該是 到 3600 之間；在發(fā)現(xiàn)了這個(gè)錯(cuò)誤后 CKPT 進(jìn)程終止了 ASM 實(shí)例。

似乎問題就很簡單了， parallel_max_servers 被置為 4505 ， ASM 實(shí)例終止，進(jìn)而導(dǎo)致 DB 實(shí)例終止 。 那么，這里我們就需要搞清楚幾個(gè)問題：

對(duì)于這種硬性設(shè)定，我們不妨先查一下官方手冊(cè)，查看該參數(shù)是否有上限值：

可以看到，該值設(shè)定的上限就是 3600 ；

正常情況下，如果我們?cè)跀?shù)據(jù)庫中的 修改 參數(shù)， 修改失敗直接拋錯(cuò)即可，顯然并不會(huì)導(dǎo)致數(shù)據(jù)庫實(shí)例的重啟；

而這里發(fā)生的重啟，我們可以看到導(dǎo)致重啟的進(jìn)程是 CKPT 進(jìn)程：

我們可以認(rèn)為， CKPT 進(jìn)程是數(shù)據(jù)庫實(shí)例的關(guān)鍵進(jìn)程，當(dāng)它遇到錯(cuò)誤時(shí)，它直接終止了整個(gè)實(shí)例；

通常來說，修改（調(diào)大）parallel_max_servers參數(shù)的目的是允許系統(tǒng)啟動(dòng)更多的并行進(jìn)程；而對(duì)于ASM實(shí)例來說，修改這個(gè)參數(shù)本身似乎并沒有太大的意義，畢竟ASM實(shí)例都不會(huì)open，基本只服務(wù)于Database（可能還有一些監(jiān)控/管理類的語句）；那么誰會(huì)來修改ASM實(shí)例上的參數(shù)呢？難道是應(yīng)急的時(shí)候錯(cuò)把ASM實(shí)例當(dāng)做Database了？

看到這里，不妨思考一下？原因其實(shí)很簡單 …..

我們?cè)趤砜纯碅SM的日志，相關(guān)的信息值得思考：

我們可以看到，在參數(shù)調(diào)整之前，日志中實(shí)例發(fā)現(xiàn)了CPU count變成了228，緊接著系統(tǒng)就調(diào)整了parallel_max_servers值的大小，隨后報(bào)錯(cuò)宕實(shí)例；

這里我們首先需要確認(rèn)，CPU數(shù)的調(diào)整會(huì)引起parallel_max_servers參數(shù)的調(diào)整嗎？我們?cè)賮砜纯催@個(gè)參數(shù)的相關(guān)屬性，其默認(rèn)值確實(shí)就是與CPU_COUNT有關(guān)的，而且參數(shù)本身就是可以動(dòng)態(tài)調(diào)整的；

很顯然，這里Oracle的代碼中似乎在系統(tǒng)調(diào)整CPU進(jìn)而導(dǎo)致parallel_max_servers參數(shù)的動(dòng)態(tài)調(diào)整時(shí)，忘記了該考慮parallel_max_servers還有一個(gè)3600的上限，這應(yīng)該定義為一個(gè)bug；我們上MOS核查也很快能找到這個(gè)bug：

問題發(fā)生在11.2.0.2和11.2.0.3的版本上，在11.2.0.4版本上已經(jīng)修復(fù)；

看著問題是得到了圓滿的分析，然而還有不少疑惑縈繞在我的心頭，也是客戶所關(guān)注的，所以這里先來解答這些問題；

1. 為什么 Database 實(shí)例沒有因?yàn)? parallel_max_servers 的參數(shù)調(diào)整而直接重啟呢？

這里我們可以再回過頭來看 database instance 的 alert 日志信息 ：

同樣也看到了 CPUcount 的變化，調(diào)整到了 228 ；但是并沒有出現(xiàn) parallel_max_servers 參數(shù)的動(dòng)態(tài)調(diào)整，其實(shí)這里主要的原因是，在 Database 實(shí)例中，我們已經(jīng)在參數(shù)文件中指定了 parallel_max_servers 參數(shù)的大小了，在指定了參數(shù)的情況下，系統(tǒng)不再根據(jù) CPU 數(shù)動(dòng)態(tài)調(diào)整 parallel_max_servers 參數(shù)的大??；

2. 為什么 ASM 實(shí)例啟動(dòng)時(shí)，沒有再因?yàn)樵搮?shù)而無法啟動(dòng)？

在 ASM 再次重啟的時(shí)候是怎么計(jì)算 parallel_max_servers 參數(shù)值的呢？實(shí)際上我們搜索 asm 的 alert 日志發(fā)現(xiàn)啟動(dòng)實(shí)例是并沒有設(shè)定 parallel_max_servers 參數(shù)；而我們手動(dòng)設(shè)定 asm 的 parallel_max_servers 參數(shù)值也會(huì)報(bào)錯(cuò)：

我們發(fā)現(xiàn)，在 ASM 實(shí)例中壓根就無法設(shè)置這個(gè) parallel_max_servers 參數(shù)，哪怕是設(shè)定到 spfile 中也不允許；實(shí)際上在啟動(dòng)時(shí)不計(jì)算、不檢查這個(gè)參數(shù)也就合乎情理了；

3. 剛剛調(diào)整上去的 CPU 我再調(diào)回來還會(huì)宕機(jī)嗎？

我們從原理上看，這里數(shù)據(jù)庫并不關(guān)心 CPU count 是變大還是變小，一次是變十個(gè)還是變一個(gè)，它都會(huì)重新來計(jì)算 parallel_max_servers 參數(shù)的值，那么顯然，這里如果再次調(diào)整 CPU count ，如果不是將 CPU count 調(diào)整到足夠小，那么再次調(diào)整只要調(diào)整后的 CPU count 數(shù)計(jì)算 parallel_max_servers 參數(shù)的值大于 3600 ，問題將再次出現(xiàn) ！

4. 如何預(yù)防這樣的問題呢？

已經(jīng)知道了這是 bug ，那么對(duì)應(yīng)的打上相應(yīng)的補(bǔ)丁一定是根本的解決之道；

而數(shù)據(jù)中心 11.2.0.3 版本的系統(tǒng)還非常多，而動(dòng)態(tài)調(diào)整 CPU 也是常見動(dòng)作，統(tǒng)一安裝補(bǔ)丁也需要時(shí)間，同時(shí)還需要考慮時(shí)間窗口，肯定需要一定的周期；那么在此之前我們是否還有臨時(shí)的預(yù)防之策呢？

根據(jù) bug 文檔描述的 workaround 是手動(dòng)指定 parallel_max_servers 參數(shù)為小于 3600 的值，不過我們上面的核查能很明白的看到， ASM 實(shí)例無法調(diào)整該參數(shù)，看來官方文檔沒有考慮 ASM 實(shí)例的情況，也有紕漏，那么我們?cè)撛趺崔k呢 ？

該如何是好呢？如果是你，你會(huì)考慮一些什么來規(guī)避這類問題呢？

要從根本上來回答上面的這些問題，其實(shí)需要了解數(shù)據(jù)庫到底是如何計(jì)算 parallel_max_servers 參數(shù)的；實(shí)際上我們可以看看如下描述：

從上述描述我們可以看到影響參數(shù)的若干變量，包括：

PARALLEL_THREADS_PER_CPU ：該參數(shù)基于操作系統(tǒng)，通常是 2；

CPU_COUNT ：該參數(shù)基于數(shù)據(jù)庫的實(shí)際 CPU 數(shù)，但是可以調(diào)整；

concurrent_parallel_users ：該參數(shù)基于實(shí)例的內(nèi)存管理模式配置，默認(rèn)系數(shù)為 1/2/4 不等；

PROCESSES ：該參數(shù)值來實(shí)例啟動(dòng)時(shí)的 PROCESSES 參數(shù)；

可以看到， parallel_max_servers 的參數(shù)值通過兩方面的計(jì)算取 min 值，也就是取自 min(parallel_threads_per_cpu*cpu_count*concurrent_parallel_users * 5,processes-15) ；這兩個(gè)方面來看，其中一部分確實(shí)與 CPU 有關(guān)，而另一方面似乎只與 processes 有關(guān)，我們?cè)俨? 11.2 的 references：

processes 參數(shù)的值默認(rèn)是 100 ；如果沒有人調(diào)整過 ASM 實(shí)例的 process 參數(shù)的值的話，那么這里計(jì)算 parallel_max_servers 的值應(yīng)該是 min( PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5,100-15 ) ， 這里即使前面計(jì)算的值再大，這里計(jì)算出來的值也只應(yīng)該是 85 而已 ，也就遠(yuǎn)不會(huì)超過 3600 ；

 難道 真的是又有誰修改了 ASM 實(shí)例的 PROCESSES 參數(shù)值嗎？還是官方的 reference 是錯(cuò)誤的呢？如果是你，你會(huì)怎么進(jìn)一步核查這個(gè)參數(shù)呢？

遇到這樣的情況，我們首先檢查并沒有發(fā)現(xiàn)兩個(gè)節(jié)點(diǎn) alert 日志存在修改記錄；那么難道 reference 真的有誤？事實(shí)上我們看的是 11.2 的 reference ，當(dāng)前的 11.2.0.3 版本發(fā)布時(shí)間在 reference 之后很久，我們不妨再通過 MOS 核查確認(rèn) processes 值默認(rèn)值的計(jì)算方法：

在 MOS 文檔 “ 升級(jí)到 11.2.0.3/11.2.04 Grid/ASM 所需要知道的事 ” 中指出， ASM 的 processes 參數(shù)的默認(rèn)值計(jì)算是“ available CPU cores * 80 + 40 ”，當(dāng)然，這里 processes 參數(shù)不會(huì)隨著 CPU 數(shù)動(dòng)態(tài)改變，只會(huì)在實(shí)例啟動(dòng)時(shí)計(jì)算；

我們截取之前時(shí)段 AWR 報(bào)告中拿到的 CPU cores 數(shù) ：

那么這里， parallel_max_servers 的值計(jì)算就是：

min(PARALLEL_THREADS_PER_CPU*CPU_COUNT*concurrent_parallel_users*5,last_CPU_cores*80+40-15)

代入實(shí)際值即為：

min （ 2*228*4*5, 56*80+40-15 ）即

如無必要，我們?cè)跊]有充足理由調(diào)整系統(tǒng)CPU/內(nèi)存的時(shí)候，不要輕易調(diào)整系統(tǒng)資源 ；

后續(xù)再了解整個(gè)情況后，我們?cè)倩剡^頭看系統(tǒng)投產(chǎn)過程中所謂慢的情況，其實(shí)只是大量新插入記錄的表未及時(shí)收集統(tǒng)計(jì)信息導(dǎo)致執(zhí)行計(jì)劃不夠好而造成的執(zhí)行緩慢；雖然當(dāng)時(shí) CPU 使用率相較之前確實(shí)偏高，但是在這種情況下，不通過收集統(tǒng)計(jì)信息，重新執(zhí)行語句的情況下，通過增加 CPU/ 內(nèi)存這兩種常用的應(yīng)急手段實(shí)際上毫無幫助；在本次 CASE 中，增加 CPU 的動(dòng)作反而造成了數(shù)據(jù)庫宕機(jī)！

我們?cè)賮砘仡櫿麄€(gè)事情的前后，以及數(shù)據(jù)庫本身的動(dòng)作：

從這里看，一個(gè)看似有益無害、多多益善的決定，讓一套系統(tǒng)發(fā)生了重啟，所以，應(yīng)急需謹(jǐn)慎，最好做到對(duì)癥下藥，避免出現(xiàn)意想不到的結(jié)果。

在數(shù)據(jù)庫版本為 11.2.0.2/11.2.0.3 的情況下，對(duì)于數(shù)據(jù)庫實(shí)例，建議手動(dòng)設(shè)置 parallel_max_servers 參數(shù)，對(duì)于 ASM 實(shí)例，建議手動(dòng)設(shè)置 processes 值為小于 3600 的值，避免出現(xiàn) CPU 數(shù)量過高的情況下，動(dòng)態(tài)調(diào)整 CPU 數(shù)造成的 Database/ASM 實(shí)例重啟的情況。

本文轉(zhuǎn)載于中亦安圖