[Performance] Zugriff auf riesige Tabelle

[Ines3642]

Hallo zusammen,

ich stehe aktuell vor dem Problem, Daten aus einer riesigen Tabelle lesen zu müssen.

Die Z-Tabelle hat knapp über 240mio Einträge.
Sie ist 9 Felder breit, wobei der Schlüssel inklusive Mandant 5 Felder umfasst.
Nennen wir diese Felder einfach mal KEY1 - KEY5. (wobei KEY1 der Mandant ist)
Es gibt einen Index auf die Felder, KEY1, KEY3, KEY4 und KEY5 (KEY2 fehlt im Index).

Nun habe ich einen SELECT mit einem FOR ALL ENTRIES auf diese Tabelle.
Die Interne Tabelle aus dem FAE ist genauso typisiert wie meine Z-Tabelle.
Die Felder im WHERE entsprechen dem Index - lediglich der Mandant wird nicht explizit aufgeführt.

In einer "alten" Version wurde die Tabelle mit einem SELECT.. ENDSELECT gelesen.
Dabei wurde mit einem APPENDING TABLE .. PACKAGE SIZE 10000 gearbeitet.

Wir haben diesen SELECT auf einen SELECT ohne ENDSELECT und ohne PACKAGE SIZE umgestellt.
Doch "gefühlt" ist der Zugriff nun noch langsamer...

Gibt es denn eine Möglichkeit, hier etwas schneller zu werden?

Im Schnitt erhalte ich übrigens als Ergebnis des SELECTs immer ca. 5mio Einträge.

Ich bin für jeden Tipp dankbar!

[Joeline5261]

Hallo,

könnte ihr keinen zweiten Index zu der Tabelle anlegen in der alle
Keifender enthalten sind.

Gruß
Wolfgang

[Ines3642]

Hallo Wolfgang,

ich dachte, ein Index auf den vollen Primärschlüssel baut das System sowieso immer auf? Ist dem nicht so?

[Joeline5261]

Hallo,

doch das ist so.
Verstehe aber nicht warum ihr nicht mit dem vollen Key die Daten lesen könnt.
Schon mal mit ST03 eine Analyse der Zugriffe durchgeführt ?

Gruß
Wolfgang

[Ines3642]

Vom Prozess her befinden wir uns im POS Download.
Die Z-Tabelle stellt eine Versorgungshistorie dar.
Das Feld KEY2 ist dabei das WERK.

Wir lesen diese Tabelle ausgehend von Änderungszeigern für Artikeldaten.
Die Änderungszeiger geben uns in der Regel dabei keinen Hinweis auf das WERK.
Aus diesem Grund gehen wir hier "rückwärts": wir müssen schauen, für welche Betriebe die durch die Zeiger definierten Artikel bereits versorgt wurden - und nur für diese dürfen die Änderungen dann aufbereitet werden.

[Joeline5261]

Hallo,

um den Zugriff zu optimieren habt ihr schon versucht den Select mit
mit dem. Werk between '0001' and '9999' zu ergänzen.

Damit wäre zumindest des voll qualifiziert.

Gruß
Wolfgang

[Ines3642]

Ganz so einfach ist es nicht, da wir alphanumerische Betriebe"nummern" nutzen.

Aber die Botschaft ist angekommen, wir versuchen es mal mit einer Eingrenzung der Betriebe.

Danke!

[Joeline5261]

Hallo,

seit ihr inzwischen weiter gekommen ?

Gruß

[Sascha2839]

Versuche doch einmal, den FAE in RANGES umzuwandeln. FAE setzt immer nur rund 5 parametrisierte Abfragen an die Datenbank ab, jeweils verbunden mit einem OPEN und einem CLOSE an die Datenbank. Das kostet Zeit.
Vereinfacht so:
OPEN DB
SELECT * FROM db WHERE fae[1]
SELECT * FROM db WHERE fae[2]
SELECT * FROM db WHERE fae[3]
SELECT * FROM db WHERE fae[4]
SELECT * FROM db WHERE fae[5]
CLOSE DB

Das geht solange bis die FAE-Tabelle abgearbeitet ist.

Wenn du mit Ranges arbeitest, wird die WHERE Bedingung einmal komplett an die DB gesendet, womit die Anzahl an OPEN und CLOSE Befehlen auf genau jeweils 1 reduziert wird.

Allerdings gibt es einen Haken: Sollte die RANGES Tabelle zu gross werden (>65kb), schmiert das Ganze ab, weil die DB die Abfrage nicht mehr kompilieren kann. In diesem Falle musst du mehrere male einen SELECT mit "zerstückelten" RANGES Tabellen auf die DB abfeuern.

Gruß,
Tom.

[Sascha2839]

Nachtrag: Der Index wird IMMER nur bis zur ersten Unterbrechung ausgewertet - und auch nur, wenn nicht mit <> abgefragt wird. Da in deinem Falle schon der erste Key fehlt (Mandant wird ja implizit von ABAP hinzugefügt), KANN es sinnvoll sein, die Abfrage mit SELECT * FROM tab durchzuführen (OHNE WHERE Bedingung) und im ABAP Programm selber die die Prüfung durchzuführen, ob die Felder passen. Das ist zwar sehr unschön, kann aber durchaus einen ordentlichen Schub an Performance liefern. Ich spreche da aus Erfahrung.

Gruß,
Tom.