點擊藍(lán)字 關(guān)注我們
一
前言
首先鄭重申明:本文并不是想教唆你怎么把SAP服務(wù)器搞死.
雖然你確實可以從本文中學(xué)到搞死SAP服務(wù)器的技巧,但是如果因為你對公司的抱怨而導(dǎo)致你無意中使用了本文中的方式無意中搞死了貴公司的SAP服務(wù)器.
請不要甩鍋給本文作者. 罪過在于你無意的報復(fù)之心及貴公司無意讓你擁有了報復(fù)之心.
鑒于本文可能讓部分心有芥蒂的程序員有更強的破壞力.
在文末會給出相應(yīng)的解決方案
本文主要介紹怎么無意中讓PO系統(tǒng)宕機(jī)
二
技能儲備
干壞事之前先儲備一些技能,關(guān)鍵時候才能發(fā)揮出重要的作用. 比如:節(jié)假日中讓系統(tǒng)掛掉(這對開發(fā)或系統(tǒng)維護(hù)人員無疑是最大的噩耗,美美的假期泡湯,還不一定有加班工資).
使用本文的方式之前需要先儲備如下的知識
使用PO的JDBC通道從中間表讀取數(shù)據(jù),生成消息傳遞到目標(biāo)系統(tǒng).
可能你無意中查詢到了SAP的這個幫助. 如圖一
在JDBC通道中按圖一中方式配置了發(fā)出通道的讀取語句和更新語句,如圖二
https://help.sap.com/doc/saphelp_nw73/7.3.16/en-US/7e/5df96381ec72468a00815dd80f8b63/content.htm?no_cache=true
select * from table where processed = 0
update table set processed = 1 where processed = 0
圖一
圖二
三
天時地利人和
中國傳統(tǒng)文化講究天時地利人和,三者合一方成大事. 因此要干票大的,也得考慮考慮這些因素.
01
天時
你夜觀天象,發(fā)現(xiàn)最近七星不亮,似有不吉之兆. 因此暫停了JDBC SENDER通道一段時間,恰逢元旦假期,為了安度假期,又重新打開了JDBC SENDER通道(把期間累計的幾百萬條記錄處理掉,數(shù)據(jù)量大是很重要的因素).
關(guān)于通道的暫停的方法
暫停通道的兩種方式
通道配置中設(shè)置狀態(tài)inactive(圖三)
通道監(jiān)控器停止通道(圖四)
自動啟動停止通道
詳見鏈接無峰，公眾號：ABAP 技巧與實戰(zhàn)PO系列之 通道的可用性計劃
圖三
圖四
02
地利
這個存粹湊數(shù)的, 想不到啥地利的因素. 如果要硬湊, 那么你恰好出現(xiàn)在銀河系獵戶座旋臂-太陽系-地球-亞洲-中國-某地. 是為地利
03
人和
開發(fā)和系統(tǒng)維護(hù)人員在假期中休假的休假,結(jié)婚的結(jié)婚,離異的離異. 總之各顧各的去了. 人都不在是為人和.
四
案發(fā)
然后PO系統(tǒng)就掛了. 在崗的的業(yè)務(wù)人員及時的發(fā)現(xiàn)了問題: 怎么倉庫收不到收貨單據(jù), 供應(yīng)商貨都拉到了倉庫,在等著按單收貨呢.
事件持續(xù)發(fā)酵幾個小時. 估計中國移動的營收又增加了0.00000000165890個百分點.(這個梗來自拼多多)
BASIS緊急介入. 祭出重啟大法. 重啟了PO系統(tǒng), 重啟后幾分鐘,系統(tǒng)又不響應(yīng)了. 靠,重啟都沒法解決的問題,那基本無解了.
休假結(jié)婚離異的開發(fā)人員被緊急召回:沒改任何代碼呀, 咱可是嚴(yán)格遵照中國程序員編程規(guī)范,節(jié)假日前不發(fā)布新版本.
維護(hù)人員也很冤枉: 我只是重新開啟了一個接口. 這不是正常操作么?
五
解決辦法
找到之前使用JDBC SENDER 通道訪問的表, 把處理標(biāo)記 都設(shè)置為已處理 processed = 9. 然后再重啟PO系統(tǒng). BINGO,問題成功解決. 有沒有覺得這個問題的發(fā)生和解決都有點不可思議?
六
總結(jié)
PO JDBC SENDER 通道中的SELECT 語句用于獲取數(shù)據(jù)產(chǎn)生一個消息. 如果讀取數(shù)據(jù)庫的SELECT 語句讀取了大量數(shù)據(jù),PO嘗試把所有這些數(shù)據(jù)構(gòu)造成一個巨大的XML時,出現(xiàn)系統(tǒng)宕機(jī), 重啟后, 通道重新激活,再次讀取,再次構(gòu)造,再次宕機(jī). (感覺PO好脆弱).
不太建議PO中使用JDBC SENDER 通道. 因為很難解決PO讀取數(shù)據(jù), 外部系統(tǒng)同時寫入數(shù)據(jù)的場景(序列化讀取是系統(tǒng)推薦的一種方式,需要讀寫雙方都設(shè)置序列化操作).
如果一定需要使用JDBC SENDER通道, 可以嘗試通過rownum<= N 限定一下消息的大小(ORACLE數(shù)據(jù)庫有效, 其它數(shù)據(jù)庫類型不確定)
SELECT ROWnum ,exord,flag FROM DANIANG.Zttemp
WHERE (flag IS NULL OR FLAG = '') AND rownum <= 100;
UPDATE DANIANG.Zttemp SET FLAG = 'X'
WHERE (flag IS NULL OR FLAG = '') AND rownum <= 100;
通過rownum 獲取的數(shù)據(jù)和更新的數(shù)據(jù)是否嚴(yán)格一致, 這一點有些存疑. 在JDBC SENDER 通道中怎么限定每次讀取的數(shù)據(jù)包大小? 這個問題期望讀者能給出更好的答案.
(驗證ORACLE的rownum 的獲取,select 的字段順序不一樣, 會導(dǎo)致一條記錄的rownum不一致. update 中使用的rownum 可能是基于select * 獲取的. 這就要求SELECT 語句一定不能修改字段原本順序,否則可能導(dǎo)致更新的數(shù)據(jù)和讀取的數(shù)據(jù)不一致)
THE
END
