儲存過程遇到gc cr request等待

wenhual43發表於2012-07-18
儲存過程GC
現象：
2個例項的rac ，在例項2裡執行儲存過程，prcodure內容主要是
1.drop table a;
2.create table a as select * from b;
3.create index idx_a1 on a  XXXXXX;
4.create index idx_a2 on a XXXXXX;
5.create index idx_a3 on a XXXXXX;
結果連續2天job都在第5步不動了，且都是在例項2上執行，檢查後發現等待事件“gc cr request”。
我理解該等待事件是，當一個程式訪問需要一個或者多個塊時，oracle會首先檢查自己的CACHE是否存在該塊，如果發現沒有，就會先通過global cache賦予這些塊共享訪問的許可權，然後再訪問。假如，通過global cache 發現這些塊已經在另一個例項的CACHE裡面，那麼這些塊就會通過CACHE FUSION,在節點之間直接傳遞，同時出現global cache cr request等待事件。
解決：
在例項2上手工執行第5步，還是“gc cr request”等待，殺掉後，在例項1上，手工執行，索引建立成功。然後在例項1裡面drop 這個索引，再去第二個例項裡執行，執行成功。
疑問：
這個錯誤明天還會發生嗎？gc cr request怎麼處理。明天觀察一下job執行情況。

7月27日，問題又出現了。
進一步發現：
建索引的時候，如果這時候別的節點恰好有資料泵匯出，且表不在匯出的資料庫節點的時候，會有衝突。

現象：故障時刻資料庫伺服器rac1,rac2有等待事件“cr request retry”“library cache lock”，“cursor: pin S wait on X”，waiting  的事件RAC每臺機器200個左右。應用伺服器叢集有執行緒掛起，一看還是這個儲存過程。這個儲存過程還和我幹上了，這次比較惡劣，一個索引也沒建上，前臺200多個點選查詢這個表，系統被拖住，網站頁面都打不開了。

原因分析：
    當對應的JOB殺掉後，發現後臺有gzip在執行。gzip是在資料泵匯出資料後做壓縮操作，應該是在晚上12點多執行啊。檢視crontab,發現在rac1機器上12點37分有資料泵匯出表a，而JOB正好是在rac2上執行。
    因為表a的MASTER 是rac2， rac1機器資料泵要去rac2機器上取資料、索引等資料塊。所以有cr request retry 等待事件。這時候匯出和建索引有衝突，在殺掉JOB後，匯出能順利進行.

解決辦法：

1.       把JOB和等待事件對應b表查詢會話，程式都殺掉；

2.       重起應用伺服器儘快使系統恢復正常使用；

3.       把b表查詢功能遮蔽掉，建上索引後放開；

4.       把crontab命令匯出a表的時間往後挪，保證在JOB執行完後再執行匯出任務。

疑問：在rac環境資料泵匯出表的時候，如果該表有建索引操作，表的master和資料泵不在一個節點的時候會有問題。可能是oracle的一個bug。









來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/25027760/viewspace-735933/，如需轉載，請註明出處，否則將追究法律責任。

相關文章