Tag Archives: reliable message

10.2出现reliable message信息导致进程hang死

Posted on 2012/10/15 by yangtingkun

已经在多个RAC环境碰到因为等待reliable message导致进程hang死的情况了。 这个问题在RAC环境比较常见，在很多客户中都碰到过这个问题，而数据库版本多集中在10.2.0.4，个别的版本为10.2.0.5。 而出现这个信息的进程也不太相同，最常见的的m000进程，这个进程的僵死会导致一个节点的AWR无法自动收集。 另外比较常见的就是导致高级队列机制异常，直接影响是数据泵导出无法正常运行，会导致进程挂起。 最近又碰到了类似的情况，在MOS文档中发现Bug 6148054 RAC hang waiting for “reliable message”文章描述的BUG与之前的情况非常类似，不过根据这个bug的描述，问题似乎不会在10.2.0.5上发生。其他方面现象都比较相符，而且之前碰到的大部分案例中，除了reliable message等待之外，还会有wait for unread message on broadcast channel等待。 这个bug确认的修复版本是11.1.0.6，从这个角度讲，10.2.0.5很可能也会有类似的问题。除了升级版本为，可以通过补丁7801939来解决这个问题。

Posted in BUG | Tagged , , | Leave a comment

11.2使用KEEP池导致ENQ: KO – Fast Object Checkpoint等待

Posted on 2012/10/14 by yangtingkun

前一段时间在客户测试TPCC的时候碰到这个问题，今天在MOS上找到问题的原因，简单记录一下。 在11.2中，如果表设置了KEEP池，而在初始化参数中没有指定DB_KEEP_CACHE_SIZE的值，就可能会造成数据库中出现明显的ENQ: KO – Fast Object Checkpoint的等待，同时还伴有reliable message的等待。 MOS文档ENQ: KO – Fast Object Checkpoint And Reliable Message Causing Bad Performance [ID 1377830.1]描述了这个问题，给出的解决方案是不使用KEEP池，改为使用DEFAULT池，或者设置DB_KEEP_CACHE_SIZE的值为非0。 而当时测试的过程中，问题与当前的现象很像，版本是11.2.0.2，在执行完压力测试后，所有程序断开后。如果执行关闭操作SHUTDOWN IMMEDIATE，此时就可以发现，数据库经历漫长的ENQ: KO – Fast Object Checkpoint等待，然后数据库才可以正常关闭。不过唯一的不同之处在于，当时测试环境中设置了DB_KEEP_CACHE_SIZE的值，因此问题和当前问题描述很像，但并不一样。 由于环境已经消失，现在无法验证这个问题，但是根据印象判断，这个问题可能确实和使用了KEEP池有关，在使用KEEP池之前使用默认的DEFAULT池时，数据库关闭并没有经历如此严重的等待。因此，在11.2中使用非DEFAULT池，可能会引发异常  

Posted in BUG | Tagged , , , , | Leave a comment