SQL-Ausführungsplan / DB-Schnittstelle

[Hartmut3588]

Hallo zusammen,

ich habe die Anforderung bekommen, einen uralten Report zu ergänzen.
Das Programm ist nicht sonderlich umfangreich, wirkt aber im Quellcode
durch SELECT / ENDSELECT-Schleifen und unübersichtliche Verarbeitung
der Selektionsergebnisse sehr aufgebläht.

Also habe ich das Programm neu geschrieben und habe mich dabei mit
Joins bei den Selects ausgetobt. Im Testsystem benötige ich nun 40% der Laufzeit...
Dann habe ich das Programm in das Produktivsystem importiert und war ernüchtert...
Mein Programm benötigt die 4-5 fache Laufzeit im Vergleich zum alten Programm

Im SQL-Trace (ST05) habe ich festgestellt, dass ein SQL-Statement unterschiedlich ausgeführt
wird. Nachfolgend ein paar Screenshots dazu.

Quellcode

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. FORM get_orders CHANGING ct_orders TYPE tyt_orders.
2.  
3.   CLEAR ct_orders.
4.   SELECT vbap~vbeln  vbap~posnr vbap~abgru vbap~matnr
5.          vbap~kwmeng vbap~vrkme vbap~ntgew vbap~gewei
6.          vbap~cuobj
7.          vbep~mbdat
8.          kna1~kunnr kna1~name1
9.      INTO CORRESPONDING FIELDS OF TABLE ct_orders
10.      FROM vbap
11.      INNER JOIN vbep
12.              ON vbep~vbeln = vbap~vbeln AND
13.                 vbep~posnr = vbap~posnr
14.      INNER JOIN vbak
15.              ON vbak~vbeln = vbap~vbeln
16.      INNER JOIN kna1
17.              ON kna1~kunnr = vbak~kunnr
18.      WHERE vbap~vbeln IN s_vbeln
19.        AND vbap~matnr IN s_matnr
20.        AND vbap~abgru IN s_abgru
21.        AND vbep~etenr = '0001'.
22.  
23. ENDFORM.                    " GET_ORDERS
24.  

GeSHi ©

SQL-Statement im Trace


Ausführung im Testsystem ( Primärindex bei VBEP )


Ausführung im Produktivsystem ( Full-Table-Scan VBEP )


Was kann ich da tun? Oder bin ich abhängig von der Adminstration

Viele Grüße,
Oliver

[Marion1009]

Ich nehme an, Ihr arbeitet mit Oracle...

Das Verhalten des CBO ist bei JOINs kaum zu beeinflussen.
Problematisch ist die Verwendung von Variablen durch SAP
die zwar im Regelfall günstig, aber bei JOIN auch mal ganz
ungünstig sein kann.
Hier entscheidet sich der CBO mit dem Absagegrund in die
Tabelle VBEP als primäre Tabelle einzusteigen. Der CBO
rechnet mit 73.439 Treffern in dieser Tabelle - ohne zu
wissen mit welchem Key zugegriffen wird. Für unser System
würde ich da mal 3 Nullen dranhängen; kein Wunder daß das
dermassen teuer ist.
Wenn der JOIN sauber definiert ist kann die Verwendung
des RBO Wunder bewirken (HINT RULE).
Der arbeitet die Tabellen in der angegebenen Reihenfolge ab
und wählt den Index anhand der übergebenen Where-Klausel.
(ohne Analyse-Daten).
Ich konnte bisher weder durch Index- noch durch Leading-
Hints signifikante Verbesserungen bei Zugriffen mit mehr-
stufigen JOINs erreichen (Es sei denn es sind Literale im Key).

Wenn nichts hilft musst du die Tabellen separat lesen.

Gruss
Daniel

,

[Hartmut3588]

Hi Daniel,

WOW... Vielen Dank für den Tip !!!
Ich habe %_hints oracle 'RULE'. angefügt. Laufzeit über den Daumen nur noch 15%
Auf der Seite von Enno gibt es hier auch ein paar Infos.

Ich fange gerade erst an, mich intensiver mit der "Kaffeesatz-Leserei" im SAP auseinander zu setzen. Wie bist du direkt auf die (richtige) Idee gekommen, dass wir Oracle einsetzen?

Viele Grüße,
Oliver

[Marion1009]

Wie bist du direkt auf die (richtige) Idee gekommen, dass wir Oracle einsetzen?

Der Ausführungsplan sah danach aus

Gruss
Daniel

[Hartmut3588]

Ok, da fehlt mir offensichtlich die Erfahrung.