《報表性能優(yōu)化》PPT課件

ABAP：SAP報表的性能優(yōu)化,1、關于表連接語句（INNERJOIN,LEFTJOIN.）寫報表的時候，表與表之間的關聯(lián)是不可避免的。通常而言，表連接語句要掌握的原則有：(1)將最有效的查詢條件所對應的表放在第一位。換言之，讓查詢第一個表后所得到的結果集就盡可能小。比如有一張報表叫做訂單狀態(tài)統(tǒng)計表，可能查完VBAK、VBAP后還查詢LIPS、VTTP等，界面上的查詢條件很多。不過據(jù)了解得知，該報表主要是查看昨天創(chuàng)建或前幾天創(chuàng)建的訂單。那么最有效的限制條件自然是訂單創(chuàng)建日期，以及銷售組織了，而表連接的主表宜選用VBAK。(2)確定了表連接的次序后，應考慮將查詢條件盡量限制在靠前的表里。比如選擇屏幕上有個物料號的查詢條件，而我們知道訂單VBAP和交貨單LIPS均有物料號，那就應該視情況而定，如果表連接中VBAP更早出現(xiàn)，那么WHERE子句中就使用vbapmatnrINs_matnr，反之就是lipsmatnrINs_matnr。(3)兩個表之間進行連接的時候，應考慮關鍵字段或索引字段的作用。比如查詢VTTP和LIPS時，關聯(lián)關系是vttpvbeln=lipsvbeln。那么vttp在前，lips在后，就會比較快，因為根據(jù)vttp的vbeln查詢lips時，vbeln是lips的關鍵字段，速度較快。而反過來如果lips在前，那根據(jù)lipsvbeln查詢vttp會慢一些，除非vbeln是vttp的索引字段。,2，先構建RANGE再執(zhí)行SQL語句有時我們所能用的查詢條件不是很理想，比如查詢LIKP卻必須用公司代碼，而非銷售組織。此時普通做法是用LIKP與TVKO根據(jù)VKORG進行表聯(lián)接，從而限制TVKOBUKRS的值。還有一種有效的辦法是，通過TVKO查詢到當期公司代碼所對應的全部銷售組織，從而組建一個RANGE出來，再根據(jù)此RANGE查詢LIKP。當然要注意RANGE的行項目有上限的，在ECC6中大概2萬行將導致ABAPDUMP。提示：DATAr_vkorgTYPERANGEOFlikp-vkorg.SIGN=I,OPTION=EQ,LOW=XXXX即可往r_vkorg中放入多個單值。,3，F(xiàn)orAllEntries與SelectSingle的比較就個人而言，筆者不是很喜歡ForAllEntries語句，因為它的缺點多于優(yōu)點。很多人都會說，為什么呀，F(xiàn)orAllEntries不是比SelectSingle快么？事實到底怎樣呢，讓我們做個比較。假設我們有個內表代表銷售訂單的行項目，該內表有10萬行。此時我們要根據(jù)LIPS的VGBEL和VGPOS，查詢這些訂單行項目對應的交貨單行項目。,ENDLOOP.對于SELECTSINGLE而言，由于LIPS有個VGB的SAP自帶索引，每次查詢都挺快，即便循環(huán)10萬次，速度雖然快不了但也沒什么大的危害。對于ForAllEntries的第一步，的確比SELECTSINGLE快些，本來10萬次的SELECTSINGLE，變成了1萬次的查詢（如果BASIS設置了參數(shù)為10），每次查詢10個訂單行項目。但是第二步就很慢了，暫估it_lips為8萬行，則對于it_vbap的10萬個行項目，有8萬個行項目執(zhí)行READTABLE語句平均需要4萬次才能搜索到it_lips的目標行，另有2萬個行項目將讀遍it_lips然后才發(fā)現(xiàn)沒有對應的目標行。所以我們一共需要搜索48億次，太慢了！在此針對ForAllEntries的使用提出幾點意見：（1）如果是根據(jù)某數(shù)據(jù)量大的內表用ForAllEntries讀取數(shù)據(jù)量小的配置表，比如TVAK/T006等，那不如把ForAllEntries直接去掉，把表里的幾十條數(shù)據(jù)全部取出。,（2）使用ForAllEntries時，SELECT語句后面的字段必須包含所查表關鍵字段。比如上面的vbeln/posnr就是lips的關鍵字段。如果不含關鍵字段，比如SELECTlfimgFROMlipsForAllEntries*，那么當LIPS中兩個條目關鍵字段不同而lfimg相同時，會被SAP自動過濾掉一條。（3）上面關于性能問題，應該利用BINARYSEARCH、SORTEDTABLE或者HASHEDTABLE來解決。詳見下面第四節(jié)。4，關于BINARYSEARCH/SORTEDTABLE/HASHEDTABLE的使用BINARYSEARCH即二分法查找，在保證內表按查詢字段以升序排列的時候，可以采用二分法查找。二分法查找的速度很快，最大查詢次數(shù)為log2n。以上面的例子來說，如果it_lips事先按vgbel和vgpos排好序，則每次查找最多不超過17次。則對于it_vbap的10萬個行項目，僅100多萬次就可以搞定了！當使用READTABLE語法時，如果查詢字段跟SORTEDTABLE的排序開始字段能匹配上，則SAP將自動采用二分法查找。比如it_lips是SORTEDTABLE且以vgbel和vgpos排序，則當readtable以vgbel進行查找時，系統(tǒng)會自動采用二分法。但如果readtable以vgpos和其他字段進行查找，由于vgpos并非SORTEDTABLE的第一排序字段，系統(tǒng)將采用直線查找，速度會慢很多。總之，SORTEDTABLE的排序字段次序也很關鍵。,針對STANDARDTABLE排序后可以進行二分法查找，使用SORTEDTABLE也可進行二分法查找，那么二者有什么區(qū)別呢？簡單來說，由于SORTEDTABLE自始至終都保持排序，如果需要對內部進行頻繁的插入、刪除操作，則不推薦使用SORTEDTABLE，性能會很差。而另一方面，如果我們要用的是類似LOOPATit_lipsWHEREvgbel=*的語法（而非READTABLE）時，對于STANDARDTABLE就無法采用二分法查找，或者說會很麻煩。而對于SORTEDTABLE，系統(tǒng)會自動采用二分法優(yōu)化查找過程。至于HASHEDTABLE，筆者用得也不太多。查看SAP的標準代碼，貌似用得也沒很多。理論上HASHEDTABLE可以比SORTEDTABLE更快些，但需要耗用更大的存儲空間。當某程序采用了二分法查找之后，如果效果還不是很理想，建議可以用HASHEDTABLE試試。,5，將循環(huán)內的重復性工作進行緩沖有時我們的內表數(shù)據(jù)量很大，但又不得不在每次循環(huán)的時候，都進行類似的一些操作，比如調用函數(shù)FI_PERIOD_DETERMINE獲取某日期對應的會計年度和期間，調用函數(shù)MD_CONVERT_MATERIAL_UNIT進行單位轉換，等等。每個函數(shù)的調用背后都要執(zhí)行一系列的讀表以及運算工作，程序的效率明顯下降了。所以我們得想出有效的辦法。比如針對FI_PERIOD_DETERMINE的調用，可以改用循環(huán)前對函數(shù)G_PERIODS_OF_YEAR_GET的調用。根據(jù)公司代碼BUKRS讀取T001-PERIV，然后調用G_PERIODS_OF_YEAR_GET獲取某會計年度每個會計期間對應的起始日期和結束日期。這樣在循環(huán)內部，只要根據(jù)上面的結果即可算出某日期對應的會計年度和期間了。又比如針對MD_CONVERT_MATERIAL_UNIT的調用。相信對于it_vbap的10萬個行項目，物料號重復的有很多。所以可以先匯總物料號，然后一次性讀取表MARM以存儲換算關系。有了MARM的換算關系，循環(huán)中大量的單位換算就可以自己算了，如果無法換算的再考慮調用函數(shù)MD_CONVERT_MATERIAL_UNIT。（函數(shù)MD_CONVERT_MATERIAL_UNIT除了讀取MARM的換算關系，還會考慮同一維度單位間的換算關系比如G和KG的關系，所以其功能更強大。）,6，關于字段的增強以及TABLEINDEX的創(chuàng)建這里提到字段的增強，主要是性能方面相關的。假設我們需要基于系統(tǒng)所有的billingdocument做個動作，比如將其導出到金稅系統(tǒng)。至少有兩種方案：第一是新建一個表，專門記錄已經導出到金稅的開票憑證；第二是在系統(tǒng)標準的開票憑證抬頭表vbrk中新增一個字段，記錄是否已導出到金稅。用戶在處理業(yè)務的時候肯定會反復查詢“未導出到金稅”的所有開票憑證。那么第一種方案下，我們需要先查詢VBRK表（比如得到1萬條記錄），然后針對自建表的記錄（比如得到9800條記錄）做個減法，最后得到200條記錄的結果集。而第二種方案就快多了，查詢VBRK的時候判斷新字段=“未導出”即可。隨著業(yè)務的持續(xù)，VBRK表的條目將越來越多，而“未導出”的條目則會維持在一個較為平穩(wěn)的數(shù)字上，為了有效區(qū)分歷史數(shù)據(jù)和現(xiàn)用數(shù)據(jù)，可添加TABLEINDEX，提高報表的查詢速度。很多SAP標準表都自帶了一些索引，這些索引大都比較實用。,創(chuàng)建索引需要注意以下幾點：（1）索引會占用額外的數(shù)據(jù)庫空間，還會降低插入/修改的速度（雖然可提高查詢速度），所以需要考慮實用性，肯定不是越多越好。如果表中已有類似的索引，則不推薦新建。而對于容量大的、被多個程序訪問的表加索引就更要謹慎了，比如VBFA、MSEG、FAGLFLEXA、LIPS、VBAP、EDIDC、STXH等等。（2）創(chuàng)建索引時應注意字段的先后次序，MANDT是必須的而且都要放在第一位。字段的先后次序取決于實際業(yè)務需要。另外索引的字段不宜太多，字段越多占用的數(shù)據(jù)庫空間就越多，對于插入/修改的影響也更大。,7，選用一些替代表/替代字段（VBFA,SHP_IDX_）曾做過一些類似于“未揀配交貨單”、“未發(fā)貨過賬交貨單”的報表，剛開始用的是LIKP、VBUK等表，速度并不理想。后來調試了標準程序VL06O，發(fā)現(xiàn)其用的表是SHP_IDX_PICK、SHP_IDX_GDSI等。原來系統(tǒng)在創(chuàng)建交貨單的時候，也會更新這些臨時表。當揀配完成，該條目就從SHP_IDX_PICK中刪除。所以表SHP_IDX_PICK的條目數(shù)始終不多，查詢速度很快。同樣的，當我們在多個表中進行查詢時，可能不同的限制條件都能達到同樣的結果集，但效率差異就很大，所以選用有效的字段非常關鍵。比如需要查詢某銷售組織某天已發(fā)貨的銷售訂單，我們可以將VBAP與LIPS聯(lián)查。此時查詢條件VBAK-LIFSK=SPACE或VBAP-ABGRU=SPACE并不影響查詢結果，但它們可以在第一時間就排除大量無