某客户操作人员反应很慢不能操作，管理人员登录小机系统后发现cpu使用到了96%。而且这种情况持续了几个月。以下是登录后小机后载取的topas图,而且是周末，并没有人使用系统。小机是ibm的550,配置是2颗6核的cpu,内存是48g。
如是登录数据库执行以下脚本来查看当前数据库消耗cpu最多的进程在执行什么
从上面的信息可以看到这些进程的等待事件为kksfbc child completion，ksdxexeotherwait。当看到这种情况时第一反应是不是遇到的bug，以kksfbc child completion为关键字到mos查询可以找到,该bug的症状为进程不断spin且hang住、出现’kksfbc child completion’等待事件、还可能伴有’waits for “cursor: pin s”‘等待事件，直接影响的版本有11.1.0.6、10.2.0.3和10.2.0.4。而我这里的版本是10.2.0.1。
对于该bug的描述是在发生’kksfbc child completion’等待事件后会话陷入无休止的自旋(spins)中，这种自旋(spins)发生在由堆栈调用(stack call)kkssearchchildlist->kkshgnc陷入对kkssearchchildlist函数的无限循环中。需要更详细的stack call，如是对系统进程90116进行跟踪。
查看生成的跟踪文件orcl_ora_90116.trc有如下内容:
可以从以上trace中看到会话确实曾长时间处于’kksfbc child completion’等待中，之后陷入无限自旋(spins)中消耗了大量cpu时间。但这里实际的表现又存有差异，引发无限循环的函数是kksfbc而不是kkssearchchildlist(常规的调用序列是:kksparsecursor->kkspsc0->kksfbc ->kkssearchchildlist->kkshgnc)。kksfbc意为k[kernel]k[kompile]s[shared]f[find]b[best]c[child]该函数用以在软解析时找寻合适的子游标，在10.2.0.2以后引入了mutex互斥体来取代原有的cursor pin机制，mutex较latch更为轻量级。虽然mutex的引入改变了众多cursor pin的内部机制，但kksfbc仍需要持有library cache latches才能扫描library cache hash chains。另一方面当kksfbc函数针对某个parent cursor找到合适child cursor后，可能使用kkschlpinx方法将该child cursor pin住，这个时候就需要exclusive地持有该child cursor相应的mutex。oracle在10.2.0.4上提供了该bug的one-off patch
8575528,其在10.2.0.4 psu4以后的等价补丁为(equivalent patch)为merge patch 9696904：8557428 9696904 7527908 both fixes are needed. 6795880 superceded by 8575528 in 9696904 which includes extra files so may cause new conflicts。但merge patch 9696904目前仅有linux x86/64平台上的版本，而问题数据库所在平台为ibm aix on power systems (64-bit)，而且版本是10.2.0.1。那么要解决这个问题是不是没有办法了，其实不然，我们可以将数据库从10.2.0.1升级到10.2.0.5来解决这个bug，在升级到10.2.0.5之后确实解决这个问题。