定位rac環境中某條sql執行時間過長

    今天早上開發人員反應昨晚跑的一個儲存過程到今天早上還沒執行完，於是sqlplus登陸例項1和例項2，查詢到該存過程是連線自例項1的，而該儲存過程對應的sql語句已經執行了10多個小時，現在會話處於cr request retry等待事件中，透過v$session的p1和p2列確定了該事件正在等待14號檔案的68859號塊，然後透過dba_extents又進一步定位了該塊位於X表上，且例項1上還有若干會話也都處於cr request retry等待時間中，透過v$session的sql_id與v$sql的sql_id關聯查詢到這些sql都共同訪問了X表。
     在例項1上查詢到的都是對65589號塊的請求，並沒有發現持有該塊資源的會話，這時覺得持有該資源的會話應該在例項2上，於是連線自例項2，透過對v$session的查詢發現也有若干會話處於read by other session等待事件中，還有1個會話處於de file sequencial read等待事件中，而這個會話長時間一直在對65589號塊進行讀取操作，這時懷疑問題的根源應該是這個會話的問題。和開發人員溝通後確認這個會話對應的sql是個分頁查詢，可以kill掉這個會話，於是透過關聯v$process確認spid後，在os上殺掉了該程式，然後馬上查詢例項2和例項1上的會話情況，這時相關等待事件全部消失，開發人員再次手動執行儲存過程，此時該儲存過程可以在規定時間內順利跑完。
      這裡還有一點疑惑就是什麼原因導致例項2上那個會話一直處於對65589塊的db file sequencial read等待事件中。。。。。。。