Solaris上運行248天后會觸發bug1094190

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

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

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

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

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

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

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

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