做補丁分析的時候,無意間發(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)致的。當(dāng)出現(xiàn)問題的時候,進程的堆棧會如下所示
sslssalck <- sskgxp_alarm_set <- skgxp_setalarm() <- sslsstehdlr()<- __sighndlr() <- call_user_handler() <- __pollsys() <- _pollsys()
這提醒我們一但出現(xiàn)這類的問題,需要對相關(guān)進程做errorstack,或者11g做3級的hang analyze也行。當(dāng)然這篇note還提到了另外一個問題。在非RAC和ASM的環(huán)境下也可能出現(xiàn)該問題,甚至當(dāng)你在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