From: Wang, Jerry

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

Subject: FW: custom development in IC search for Customer

下面是SAP CRM One Order搜尋進入DB層處理的入口。
如果我只按照Service order的creation date搜，在後臺的標準實現還是和我們own的product search類似，最後拼open sql。

拿到guid之後，再從index table裡取其他欄位:

之所以出現99.7%時間花在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點到7點就有6259個新訂單生成，那麼一個月之內的訂單數量是個非常龐大的數字，所以FOR ALL ENTRIES效能非常差。

但是第一個版本就用的For all entries，可能當初寫程式碼的時候沒有考慮潛在的效能問題。IBASE和PRODUCT的實現裡都用的OPEN CURSOR +PACKAGE SIZE。

即使底層DB是HANA, 在資料庫執行搜尋時，FOR ALL ENTRIES IN it_table一樣會把it_table裡的所以entry展開成
IN( A, B, C, D, E … )的execution plan然後執行，效率不高。