昨晚的進程鏈居然報錯了,問題很詭異
這是一個GL的模型,infopackage每次執行都說Error occurred in the data selection ,在BW這邊查過ST22和SM21,都沒有異常。
後來一想,人家都說了,問題出在Extraction的時候,應該去R3查啊
於是Environment--》Job Overview--》Source System
果然啊,是被取消的,也就是說這個東西並不是現在出的錯,而是源於過去
PS:之前碰到過一次很噁心的,是因為R3那邊後台進程佔用了Extractor的資源,一直黃燈而且資料保持0條。
另外,也不能小看Monitor的Step-By-Step Analysis,有些時候還是很好用的,不過最好用EN登陸,翻譯上會有問題。這裡也會告訴你問題出在Source System。
好吧,既然問題出在R3,那到底是什麼問題呢。
SM59,測下RFC串連,沒問題啊
SM51,看看server,active,很正常
SM50
去看看後台有啥在跑呢,點了下CPU那個按鈕,發現有一個Process已經執行了大約19個小時,帳號居然是我的...嘿,這不是昨天下班兒那會兒的嘛
折回到SM21,看了下果然有錯誤
於是乎,二話不說,直接幹掉Process,回來再做抽取,萬事OK
其實總結起來,也蠻簡單的,要麼是BW這邊出了問題,也許是啟用呀,常式呀,資料呀,或者比較變態的FI資料來源上傳順序呀,等等,有的時候會因為session、process到了閥值啊,或者RFC的問題,日誌滿了,資料表空間滿了,節點滿了,都有可能影響資料幫浦。不過相對來說比較好找,畢竟有Basis在。
到了R3那邊就相對麻煩了,問題也很繁瑣,特別是對於增強過的資料來源,我遇到過那種直接跑死的不過跑到SM50幹進程也倒是一勞永逸的方式,但是要注意安全。
另外,陳老師有一篇部落格,講的也蠻好,不過沒怎麼用到過這麼複雜的。轉來
如何處理大資料量抽數長期無響應?
在一個項目上線過程中,由於一些模型資料量巨大,抽數十分緩慢,長期在黃燈狀態,monitor的訊息是:missing messages.
處理幾次類似問題後,總結了一點經驗:
首先檢查系統的一些參數設定是否正確,和抽數相關的參數包括:
1. 檢查系統連結是否正常:SM59
2. SBIW進行傳輸設定:
IDOC頻率:多少個資料IDOC後返回一個訊息IDOC(monitor中,要收到訊息IDOC才能確認資料轉送完成,否則一直等待直到報missing messages錯誤)。當IDOC資料包比較大時,建議降低頻率,這樣可以及時發現問題。一般在5-10之間,不超過20。
IDOC資料包:每個資料包包含幾條記錄,通常在5000~20000之間。一般,每個載入進程不要超過100個資料包,因此大抽取大量業務資料時,最好將該值設得大一點。例如:50000(oracle/sql server)或10000(informix)
3. 根據資料量,估計設定infopackage執行時的最長等待時間, 並設定好timeout的時間
4. 設定TRFC最大串連數:SM58
然後,根據監控器反饋的資訊及時處理問題:
1. 若監控器的xxxx from yyyy一直在變化,說明資料一直在傳輸中,正常情況下會一直到xxxx=yyyy,yyyy為源的資料量。
2. 若監控器的xxxx from yyyy不動了,則有問題,應當看看detail的訊息。一般會出現missing messages, 是抽數線程太多造成SQL 死結。這時,則應通過SM50觀察抽數進程是否扔在工作。若抽數進程不動了,應去SM58觀察TRFC的情況,手工執行(F6)死結的TRFC以及長時間等待的TRFC。此時SM50中的進程應該繼續工作了。
3. 觀察監控器,直到資料全部抽取到BW並完成處理。若資料全部抽完(xxxx=yyyy),但一直出於missing messages的黃燈或紅燈狀態,則可以手工置紅request,然後手工更新資料包,然後再手工置綠。有時,還需要手工roll up.
4. 資料量大的話,最好先做full update,然後再做無資料的initial
5. 資料量很大的話(千萬以上),full update時,最好按時間段或憑證號分次上數。
這個是很早之前寫的,講的不夠全面,先放上來,有時間再慢慢改。歡迎大家補充...
滿懷希望,期待未知的旅程。
Pasted from <http://blog.vsharing.com/WKingChen/A1151720.html>