某客戶操作人員反應很慢不能操作，管理人員登入小機系統後發現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之後确實解決這個問題。