Sent: Wednesday, June 11, 2014 12:13 PM

關(guān)于同時更新兩個database table的方法可以總結(jié)成以下三種。詳細(xì)的測試代碼在附件，感興趣可以看看。

表1在normal的work process里進(jìn)行update，表2通過update function module進(jìn)行update。
n 如果表2更新出錯，或者是更新表2的update function module 沒有通過COMMIT WORK 觸發(fā)，就會出現(xiàn)表1成功更新，但表2未更新的inconsistent狀態(tài)。

表1和表2分別在不同的兩個update function module里更新

表1和表3的更新放在同一個update function module里更新

我用不同顏色標(biāo)注這三種方法，是因為法2和法3從技術(shù)上說兩張表要么都成功更新，要么都未更新，不可能出現(xiàn)不一致的狀態(tài)。
只有方法1可能會出現(xiàn)不一致的狀態(tài)-----但是很不巧PCM 的代碼就采用的法1來更新history table和order table這兩張表。

所以yinqiang的這個結(jié)論，對于法2和法3來說是絕對正確的，但不適用于法1.

如果單純從技術(shù)上分析為什么status 更新沒有成功，標(biāo)準(zhǔn)程序里: release一個order時狀態(tài)從UNPR改成PROC是在下面的update function module里執(zhí)行:

通過ST05 trace可以確認(rèn):

所以如果status沒有更新成功，可能的原因就下面幾種:

更改狀態(tài)的update function module ( line 65 ) 執(zhí)行失敗

2. FM CMS_LO_STATUS_PREPARE_UPD_DB 輸出的lt_records_to_update 為空，導(dǎo)致update function module 實際上沒有執(zhí)行，因為task隊列為空 3. 執(zhí)行完line 65的FM之后，status 又在其他地方被修改成了UNPR（包括客戶自己的enhancement）

系統(tǒng)的邏輯是先在當(dāng)前session修改history table，然后在update work process （一個新的session里更新header status）:

看callstack能發(fā)現(xiàn)header status change是在一個新的update process里:

當(dāng)系統(tǒng)負(fù)載重的時候，可能會導(dǎo)致系統(tǒng)沒有空閑的update work process，從而header的status沒有機(jī)會得到更新:

通過將update function call改成local update的方式，可以排查到底是不是這個問題引起的。

關(guān)于yin qiang slide里的這個觀點，我個人有不同的觀點:

現(xiàn)在蒙牛更新history table是采用online 更新，而header status是采用update task的方式更新，技術(shù)上來說如果后者出錯，理論上是有可能存在history table已經(jīng)成功更新，但是header status仍然未更新的情況發(fā)生。

可以通過下面的report來模擬: line 14 更新history table，在Function module ZSQFB里更新header status.

執(zhí)行report即可發(fā)現(xiàn)history table成功更新，但header status未更新。

要獲取更多Jerry的原創(chuàng)文章，請關(guān)注公眾號"汪子熙":

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的蒙牛 customer Project Support - 同时更新两个database table的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。