Solaris上运行248天后会触发bug1094190

做补丁分析的时候，无意间发现了这个bug，大致的看了下，还是很奇葩的，这个bug几乎横跨了Oracle数据库所有的主流版本。这让我不禁联想到以前遇到的几次Solaris Crash的问题。后来也没查出个什么原因，就看了下等待事件，就给冠以了一个罪名。那么来看看这个

做补丁分析的时候，无意间发现了这个bug，大致的看了下，还是很奇葩的，这个bug几乎横跨了Oracle数据库所有的主流版本。这让我不禁联想到以前遇到的几次Solaris Crash的问题。后来也没查出个什么原因，就看了下等待事件，就给冠以了一个罪名。那么来看看这个bug的描述：在RAC环境中,ASM和DB进程可能会在运行248天之后,会产生CPU Spin的现象，这个问题是由于一个错误的C编译器优化导致的。当出现问题的时候，进程的堆栈会如下所示

 sslssalck 
这提醒我们一但出现这类的问题，需要对相关进程做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, 感谢原作者分享。