Workaround for hanging SQL Statement "DELETE Article" in replication

在處理Oracle複寫到SQL Server的問題之中，最令人難解跟抓狂的，莫過於LogReader在Oracle端執行類似以下的語法時，卻莫名的耗費大量時間，導致複寫機制整個停住：



DELETE FROM HREPL_ARTICLE326LOG_1 l
 WHERE EXISTS (SELECT p.POLL_POLLID
          FROM HREPL_POLL p
         WHERE CHARTOROWID(l.ROWID) = p.Poll_ROWID
           AND p.Poll_PollID = :Pollid)


這個問題目前尚未有答案，只知道一旦這個罕見的情況發生，整個複寫機制形同宣告死亡；如果這種情況在六日發生，禮拜一你來公司才發現的話，最好也檢查一下Oracle的UNDO Tablespace，因為它將產生大量的UNDO資料，很有機會將UNDO Tablespace搞爆；前兩次發生時我只能癡癡的拆掉重建 replication的機制(觀念沿襲於windows不穩定就FORMAT掉 XD)，但今天總算試出一個workaround，解法如下：

1. Kill掉Oracle上的Logread.exe session
2. 找出所有Oracle端的article
3. 刪除所有article的資料(強烈建議用truncate table)
4. 打開複寫監控器觀察

過個一兩分鐘，複寫機制應該就可以復活了。


後記：

好事果然不能說出來，快樂指持續了一個下午就結束，隔幾天的DELETE ARTICLE還是會死掉。想破頭來探究原因，同事提出是否有可能統計值已經失真的問題，並且利用anaylze的方式證明似乎可以讓DELETE ARTICLE變快；那好，死馬當活馬醫，排程所有ARTICLE以及 HREPL_POOL都在適當時間做統計值分析後(改用DBMS_STATS.GATHER_TABLE_STATS處理才不會lock table，而參數ESTIMATE_PERCENT需設定成100強迫上工)，的確可以明顯改善這問題。看來這種大量刪除跟新增的複寫機制，Oracle可要另外加工才能處理得好啊。@@....