2010 Sep 03 4:20 PM
This is taking a really long time. Any input in how to tune? DBA suggested a index on BSIS table using only one field HKONT.
And also possible creating index on BKPF using MANDT,GJAHR, BSTAT, BELNR.
Any thoughts would be appreciated.
SELECT F~BUKRS F~MONAT P~HKONT F~CPUDT F~BLDAT F~BLART X~TXT20 F~XBLNR
P~PRCTR Y~KTEXT P~KOSTL Z~KTEXT F~BELNR P~WRBTR P~SHKZG F~USNAM
F~PPNAM F~GJAHR J~BUTXT P~BUZEI F~WAERS
INTO TABLE ITAB_REC FROM BSIS AS P
INNER JOIN BKPF AS F ON P~BUKRS = F~BUKRS AND
P~GJAHR = F~GJAHR AND
P~BELNR = F~BELNR
INNER JOIN T001 AS J ON P~BUKRS = J~BUKRS
INNER JOIN SKAT AS X ON P~HKONT = X~SAKNR
LEFT OUTER JOIN CEPCT AS Y ON P~PRCTR = Y~PRCTR AND
Y~SPRAS = SY-LANGU AND
Y~KOKRS = P_KOKRS
LEFT OUTER JOIN CSKT AS Z ON P~KOSTL = Z~KOSTL AND
Z~SPRAS = SY-LANGU AND
Z~KOKRS = P_KOKRS
WHERE F~BUKRS IN S_CO_CD AND
F~BSTAT = ' ' AND
F~BUDAT IN S_PST_DT AND
F~BLART IN S_DOC_TY AND
F~BLDAT IN S_DOC_DT AND
F~CPUDT IN S_ENT_DT AND
F~GJAHR IN S_FIS_YR AND
F~MONAT IN S_FIS_PD AND
F~XBLNR IN S_REF_CD AND
F~BELNR IN S_DOC_NO AND
F~PPNAM IN S_PARKBY AND
P~HKONT IN S_AC_NO AND
P~PRCTR IN S_PRCTR AND
P~KOSTL IN S_CSTCTR AND
X~SPRAS = SY-LANGU AND
X~KTOPL = P_KTOPL.Edited by: Thomas Zloch on Sep 3, 2010 5:31 PM - code tags added
This is taking a really long time. Any input in how to tune? DBA suggested a index on BSIS table using only one field HKONT.
And also possible creating index on BKPF using MANDT,GJAHR, BSTAT, BELNR.
Any thoughts would be appreciated.
SELECT F~BUKRS F~MONAT P~HKONT F~CPUDT F~BLDAT F~BLART X~TXT20 F~XBLNR
P~PRCTR Y~KTEXT P~KOSTL Z~KTEXT F~BELNR P~WRBTR P~SHKZG F~USNAM
F~PPNAM F~GJAHR J~BUTXT P~BUZEI F~WAERS
INTO TABLE ITAB_REC FROM BSIS AS P
INNER JOIN BKPF AS F ON P~BUKRS = F~BUKRS AND
P~GJAHR = F~GJAHR AND
P~BELNR = F~BELNR
INNER JOIN T001 AS J ON P~BUKRS = J~BUKRS
INNER JOIN SKAT AS X ON P~HKONT = X~SAKNR
LEFT OUTER JOIN CEPCT AS Y ON P~PRCTR = Y~PRCTR AND
Y~SPRAS = SY-LANGU AND
Y~KOKRS = P_KOKRS
LEFT OUTER JOIN CSKT AS Z ON P~KOSTL = Z~KOSTL AND
Z~SPRAS = SY-LANGU AND
Z~KOKRS = P_KOKRS
WHERE F~BUKRS IN S_CO_CD AND
F~BSTAT = ' ' AND
F~BUDAT IN S_PST_DT AND
F~BLART IN S_DOC_TY AND
F~BLDAT IN S_DOC_DT AND
F~CPUDT IN S_ENT_DT AND
F~GJAHR IN S_FIS_YR AND
F~MONAT IN S_FIS_PD AND
F~XBLNR IN S_REF_CD AND
F~BELNR IN S_DOC_NO AND
F~PPNAM IN S_PARKBY AND
P~HKONT IN S_AC_NO AND
P~PRCTR IN S_PRCTR AND
P~KOSTL IN S_CSTCTR AND
X~SPRAS = SY-LANGU AND
X~KTOPL = P_KTOPL.Edited by: Thomas Zloch on Sep 3, 2010 5:31 PM - code tags added
2010 Sep 03 4:36 PM
At first glance, you should add KTOPL and SPRAS to the SKAT join, also maybe DATBI to the CEPCT and CSKT joins, then a lot depends of course on how all those selection options are filled at runtime, the narrower the better. How many entries are in S_CO_CD? If more than one, then the additional HKONT index without BUKRS could maybe make a difference, you can try and discard it again if it does not help.
Have you checked how the CBO handles the execution plan via an ST05 SQL trace? Please post it here.
Thomas
2010 Sep 03 6:23 PM
Thomas is right about checking the trace and certainly about it being selection-dependent, though I have a feeling the trace results are going to look incredibly confusing with that many joins. I would start by taking all of the text retrieval joins out of the main selection and focus on tuning the 'primary join' with BKPF and BSIS. Capture the texts that you need with FOR ALL ENTRIES or another approach. All you're doing with that many joins is handicapping the optimizer. Also, I disagree with the index suggestions, though you would certainly need to look at the statistic spread to validate it. Are you really selecting across many company codes or without company code at all? You may also benefit by analyzing your clearing procedures for those G/L accounts.
| User | Count |
|---|---|
| 3 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |