做補丁分析的時候，無意間發(fā)現(xiàn)了這個bug，大致的看了下，還是很奇葩的，這個bug幾乎橫跨了Oracle數(shù)據(jù)庫所有的主流版本。這讓我不禁聯(lián)想到以前遇到的幾次Solaris Crash的問題。后來也沒查出個什么原因，就看了下等待事件，就給冠以了一個罪名。那么來看看這個

做補丁分析的時候，無意間發(fā)現(xiàn)了這個bug，大致的看了下，還是很奇葩的，這個bug幾乎橫跨了Oracle數(shù)據(jù)庫所有的主流版本。這讓我不禁聯(lián)想到以前遇到的幾次Solaris Crash的問題。后來也沒查出個什么原因，就看了下等待事件，就給冠以了一個罪名。那么來看看這個bug的描述：在RAC環(huán)境中,ASM和DB進程可能會在運行248天之后,會產(chǎn)生CPU Spin的現(xiàn)象，這個問題是由于一個錯誤的C編譯器優(yōu)化導(dǎo)致的。當出現(xiàn)問題的時候，進程的堆棧會如下所示

 sslssalck <- sskgxp_alarm_set <- skgxp_setalarm() <- sslsstehdlr()<- __sighndlr() <- call_user_handler() <- __pollsys() <- _pollsys()

這提醒我們一但出現(xiàn)這類的問題，需要對相關(guān)進程做errorstack，或者11g做3級的hang analyze也行。當然這篇note還提到了另外一個問題。在非RAC和ASM的環(huán)境下也可能出現(xiàn)該問題，甚至當你在SQLNET中設(shè)置EXPIRE_TIME后這個問題將會更加明顯。

那么workground是什么呢？定期重啟。這真是一個坑，不過仔細想想也未必見得是一件壞事，因為系統(tǒng)運行一段長時間后，可能會出現(xiàn)一些垃圾信息，重啟之后，這些垃圾就被清理掉了。同樣的，依賴這種重啟，我們可以做一些計劃性的停機修改任務(wù)。比如修改參數(shù)。

最后我想對solaris這個系統(tǒng)吐槽一下，我感覺這個操作系統(tǒng)運行Oracle是最爛的。從一個很基本的點說起，solaris為了能讓內(nèi)核參數(shù)動態(tài)化修改就搞出了一個project的東西。他這個想法是很好的，但是他做下來，不是很明確，這導(dǎo)致了我們在設(shè)置內(nèi)核參數(shù)的時候，既需要在/etc/system下面設(shè)置，又需要在project里面設(shè)置，特別的繁瑣。我覺得要么就和Linux一樣，設(shè)置/etc/sysctl.conf就好。要么就和AIX一樣設(shè)置成什么都是-1。不要這個修改修改，然后又那個修改修改，我們做工程師的，對這種什么都要搞一下的東西，都是有抵觸情緒的。

原文地址：Solaris上運行248天后會觸發(fā)bug1094190, 感謝原作者分享。

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com