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

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

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

Hi Jerry,

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

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

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

用個(gè)例子說(shuō)明:

有兩張表：

用一個(gè)report測(cè)試，表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)只是一個(gè)很簡(jiǎn)單的assert語(yǔ)句用于模擬update function module出錯(cuò)的情況：

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

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

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

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

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

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

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

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

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

看到這13個(gè)function被bundle到一起，

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

但是實(shí)際的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個(gè)sap luw內(nèi)的function，如果出現(xiàn)不可預(yù)料的錯(cuò)誤， 則回滾這13個(gè)function， 但是在dialog提交的兩個(gè)update已經(jīng)無(wú)法回滾 和下面的結(jié)論一致

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

總結(jié)

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

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