發(fā)送時間：2014年6月9日 下午8:54

另外我剛才做了測試，即使采用SET UPDATE TASK LOCAL將history table和header table的update強行塞到一個work process里，按照SAP現(xiàn)在的代碼設(shè)計，也不可能做到將這兩張表的update做成一個原子操作。就是說即使header table update出錯，也不會對history table的更新有任何影響。

Sent: Sunday, July 20, 2014 10:35 PM

Hi Jerry,

百忙之中打擾你， 我問個小問題， 對于你當(dāng)時的結(jié)論， 這個我有點想不通， 既然已經(jīng)使用了local update， 按道理也算是把兩張表放在了一個SAP LUW里， 為什么header出錯， history table仍舊可以更新到DB呢？

Sent: Monday, July 21, 2014 12:19 PM

“采用SET UPDATE TASK LOCAL將history table和header table的update強行塞到一個work process里 ”并不等于兩張表的update放在同一個LUW里。這兩種說法不是同一回事。

用個例子說明:

有兩張表：

用一個report測試，表1是直接online update，表2在update function module里update，由于有了SET UPDATE TASK LOCAL的keyword，使得function module ZINSERT_TABLE2 也在當(dāng)前work process內(nèi)執(zhí)行。

data: ls_jerry1 type ZJERRYTABLE1, ls_jerry2 type ZJERRYTABLE2.ls_jerry1-client = sy-mandt. ls_jerry1-inumber = 'i042416'. ls_jerry1-name = 'WANGJER'. insert ZJERRYTABLE1 FROM ls_jerry1.CALL FUNCTION 'ZINSERT_TABLE2' IN UPDATE TASK.SET UPDATE TASK LOCAL.COMMIT WORK AND WAIT.

function module內(nèi)只是一個很簡單的assert語句用于模擬update function module出錯的情況：

F8執(zhí)行report，收到期望中的update function module執(zhí)行出錯的提示:

但是SE16 里table1里檢查table1 已經(jīng)有一條entry成功插入了:

再來模擬table1 update不成功，但是table2 update成功的scenario. 將update function module改成update table2: report 仍然保持不變，這樣table1的update會由于duplicate key而失敗。 report執(zhí)行完之后，table1仍然只有1條數(shù)據(jù)，但是table2已經(jīng)insert成功了。 究其原因，在這個例子里，table1和table2的update并不是放在同一個SAP LUW里的。這行ABAP OPEN SQL insert 語句(insert ZJERRYTABLE1 FROM ls_jerry1.), 什么時候會真正地把數(shù)據(jù)寫到database server里？當(dāng)遇到顯式的database commit( COMMIT WORK ), 或者隱式的database 操作時，表1的操作就會立即寫到database里，而與表2無關(guān)。 關(guān)于這兩種不同的database commit方式，可以查看ABAP help: # Sent: Monday, July 21, 2014 1:56 PM 你要證明的這一點 1. 表1在normal的work process里進行update，表2通過update function module進行update。 n 如果表2更新出錯，或者是更新表2的update function module 沒有通過COMMIT WORK 觸發(fā)，就會出現(xiàn)表1成功更新，但表2未更新的inconsistent狀態(tài)。

你當(dāng)時提供的第一段代碼的結(jié)果是：
結(jié)果: 表1成功更新，表2更新失敗( 對應(yīng)的entry未插入到數(shù)據(jù)庫里)。
Terry comment：表1仍舊在當(dāng)前dialog wp里被隱式提交，而表2是在顯式提交后轉(zhuǎn)移到新的update wp里， 一旦在更新完表1之后， 再對表2的更新處理上失敗，表1是不會被roll back的。這是root cause。
而且另外一個點是，印度開發(fā)若干年前曾經(jīng)使用set update task local的方式（也就是local update）對表1進行處理（后來因為產(chǎn)生其他issue而放棄了local update，同時也沒有使用in update task方式， 直接使用的了online更新），現(xiàn)在想來這樣 也是無濟于事，表1依舊是在當(dāng)前dialog wp里被處理，并沒有和表2結(jié)合成一個SAP LUW. 所以始終還是會出現(xiàn)破壞數(shù)據(jù)原子性的問題。

當(dāng)前在蒙牛的case里

紅框處的兩個表更新是在一個function做的， 已經(jīng)確認沒有使用in update task方式。那么它的DB提交肯定是在自己當(dāng)前的dialog wp里做的， 不會轉(zhuǎn)移到update wp去做。

然后它下面的26行記錄， 都是使用了call function in update task方式（我check了 代碼）， 把這13個function存儲在VBMOD里， 是bundle在一個SAP LUW， 它們擁有唯一共同的update key，這個很清晰沒有問題。
那么這13個update，才需要在另外一個update wp里去提交， 在這兩個work process 轉(zhuǎn)換的過程中， 按照我們今天探討的內(nèi)容， 是否說明上邊那兩張表就被隱式的先提交了； 隨后SAP LUW里的13個function才被在update wp里提交到數(shù)據(jù)庫里， 這樣說是否更符合我們今天得到的認知。繼續(xù)往下順延這個邏輯， 如果那兩張表發(fā)生了隱式提交， 那就意味著即使后邊的這13個update在commit過程的中間步驟出錯，也只會回滾該SAP LUW內(nèi)的13個update， 而不會回滾 那兩個已經(jīng)隱式提交的表。

這也就是出現(xiàn)了history表已經(jīng)插入， 而status狀態(tài)未更新的現(xiàn)象的原因。

通過查看過去的錯誤記錄， 紅框所示行 ， 5月14號發(fā)生的update error

看到這13個function被bundle到一起，

查看上面第一行 CMS_SI_INDEX_SAVE_DB， 我們知道他是用來更新CMSD_SI表的， 下面是要進行傳值的內(nèi)表， 紅框所示的這幾行數(shù)據(jù)需要在CMSD_SI表更新成PROC狀態(tài)

但是實際的CMSD_SI這幾條狀態(tài)都是unpr狀態(tài)，這是由于上述的update error導(dǎo)致更新沒有成功。

同樣CMSD_LO_STATUS這張表的status也沒有被修改成proc

但是查看相應(yīng)的歷史表記錄，卻發(fā)現(xiàn)這一批數(shù)據(jù)已經(jīng)被插入了history表， 佐證了你之前的分析結(jié)論。
CMSD_CI_HISTORY

蒙牛的情況就是下面這種， 一模一樣， header表和history表在dialog process被commit了 隨后的update process去更新 隨后的13個sap luw內(nèi)的function，如果出現(xiàn)不可預(yù)料的錯誤， 則回滾這13個function， 但是在dialog提交的兩個update已經(jīng)無法回滾 和下面的結(jié)論一致

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

總結(jié)

以上是生活随笔為你收集整理的SAP LUW Database update discuss mengniu 蒙牛的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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