From: Wang, Jerry

Sent: Wednesday, March 19, 2014 11:54 AM

Subject: FW: custom development in IC search for Customer

下面是SAP CRM One Order搜索進(jìn)入DB層處理的入口。
如果我只按照Service order的creation date搜，在后臺(tái)的標(biāo)準(zhǔn)實(shí)現(xiàn)還是和我們own的product search類似，最后拼open sql。

拿到guid之后，再?gòu)膇ndex table里取其他字段:

之所以出現(xiàn)99.7%時(shí)間花在DB access on CRMD_ORDER_INDEX上，在于下圖第40行的FOR ALL ENTIRES。后面跟的internal table it_guids_for_update里面entry越多，性能越差。

6259 records during Mar 9th 5-7 o’clock, 1244 during Mar 8th 21-23 o’clock

例如客戶在周日上午5點(diǎn)到7點(diǎn)就有6259個(gè)新訂單生成，那么一個(gè)月之內(nèi)的訂單數(shù)量是個(gè)非常龐大的數(shù)字，所以FOR ALL ENTRIES性能非常差。

但是第一個(gè)版本就用的For all entries，可能當(dāng)初寫代碼的時(shí)候沒有考慮潛在的性能問題。IBASE和PRODUCT的實(shí)現(xiàn)里都用的OPEN CURSOR +PACKAGE SIZE。

即使底層DB是HANA, 在數(shù)據(jù)庫(kù)執(zhí)行搜索時(shí)，FOR ALL ENTRIES IN it_table一樣會(huì)把it_table里的所以entry展開成
IN( A, B, C, D, E … )的execution plan然后執(zhí)行，效率不高。

總結(jié)

以上是生活随笔為你收集整理的SAP CRM One Order关于索引表CRMD_ORDER_INDEX的一些性能问题的分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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