Datenbank Index
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
5 Beiträge
•
Seite 1 von 1
5 Beiträge
Seite 1 von 1
Hallo,
ich habe einen Select, der braucht aktuell zu lang bis er was liefert.
Es gibt einen Index MANDT/DOCNUM und mehrere die mit MANDT/ZTRACK/... beginnen.
In der SE16 mit nur docnum = '0000000000000000' (erste 500 von ca. 20 Mio) oder nur ztrack = iv_ztrack (5-10 Stück) ist quasi sofort fertig. Die gesuchten Einträge gehören eher zu den letzten hinzugefügten.
Frage: Ist eigentlich die Reihenfolge in der where-Bedingung relevant für die Auswahl des DB Index? bzw. würde eine Anpassung auf was bringen?
Alternative wäre ohne docnum zu selektieren und die paar Überflüssigen nachträglich zu löschen.
FYI: der Report stammt nicht von mir. Im Testsystem kann ich das nicht richtig testen. Daher muss ich quasi optisch beurteilen, ob die Korrektur meiner Inderin was an Performance bringt.
ich habe einen Select, der braucht aktuell zu lang bis er was liefert.
Code: Alles auswählen.
SELECT *
INTO TABLE ct_data_d[]
FROM zeedmt_zmon
WHERE docnum = '0000000000000000'
AND ztrack = iv_ztrack.In der SE16 mit nur docnum = '0000000000000000' (erste 500 von ca. 20 Mio) oder nur ztrack = iv_ztrack (5-10 Stück) ist quasi sofort fertig. Die gesuchten Einträge gehören eher zu den letzten hinzugefügten.
Frage: Ist eigentlich die Reihenfolge in der where-Bedingung relevant für die Auswahl des DB Index? bzw. würde eine Anpassung auf
Code: Alles auswählen.
SELECT *
INTO TABLE ct_data_d[]
FROM zeedmt_zmon
WHERE ztrack = iv_ztrack
AND docnum = '0000000000000000'.Alternative wäre ohne docnum zu selektieren und die paar Überflüssigen nachträglich zu löschen.
FYI: der Report stammt nicht von mir. Im Testsystem kann ich das nicht richtig testen. Daher muss ich quasi optisch beurteilen, ob die Korrektur meiner Inderin was an Performance bringt.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Hi.
Da spielt leider mehr mit als nur die "Reihenfolge".
Ganz wichtig für SAP ist die "Spezifizität" oder "Eindeutigkeit" des Index für die Auswahl und dabei haben die sogenannten Datenbankstatistiken eine wichtige Rolle. Je mehr "Einzeldatensätze" pro Index identifiziert werden können, desto eher wird der Index genommen.
In deinem Fall dürfte die Änderung nichts bringen, da die Dokumentnummer(?) mit an Sicherheit grenzender Wahrscheinlichkeit mehr Einzeldatensätze identifizieren kann als der (vermutlich öfter vorkommende) Wert in ZTRACK.
Was du machen könntest, wäre entweder ...
... einen eigenen Index anzulegen, der alle drei Felder beinhaltet, da dürfte aber die zu erwartende Datenmege Probleme machen
... oder den zu verwendenen Index mittels HINT im SELECT-Statement fix vorgeben.
Alternativ um zumindest "schneller" die Ergebnisse verarbeiten zu können, was bei großen Datenmengen nicht zu verachten ist, könnte man auch mit PACKAGE SIZE arbeiten um so zumindest einen Kurzdump wegen zuwenig Speicher zu entgehen. Im Grunde werden dann z.B. 1000 Datensätze selektiert, im Programm verarbeitet, dann werden die nächsten 1000 Datensätze selektiert usw. Die Lautzeit bleibt dann zwar gleich, aber man "sieht" zumindest, dass etwas verarbeitet wird und der Debugger bleibt nicht "ewig" im SELECT-Statement hängen.
lg ADT
Da spielt leider mehr mit als nur die "Reihenfolge".
Ganz wichtig für SAP ist die "Spezifizität" oder "Eindeutigkeit" des Index für die Auswahl und dabei haben die sogenannten Datenbankstatistiken eine wichtige Rolle. Je mehr "Einzeldatensätze" pro Index identifiziert werden können, desto eher wird der Index genommen.
In deinem Fall dürfte die Änderung nichts bringen, da die Dokumentnummer(?) mit an Sicherheit grenzender Wahrscheinlichkeit mehr Einzeldatensätze identifizieren kann als der (vermutlich öfter vorkommende) Wert in ZTRACK.
Was du machen könntest, wäre entweder ...
... einen eigenen Index anzulegen, der alle drei Felder beinhaltet, da dürfte aber die zu erwartende Datenmege Probleme machen
... oder den zu verwendenen Index mittels HINT im SELECT-Statement fix vorgeben.
Alternativ um zumindest "schneller" die Ergebnisse verarbeiten zu können, was bei großen Datenmengen nicht zu verachten ist, könnte man auch mit PACKAGE SIZE arbeiten um so zumindest einen Kurzdump wegen zuwenig Speicher zu entgehen. Im Grunde werden dann z.B. 1000 Datensätze selektiert, im Programm verarbeitet, dann werden die nächsten 1000 Datensätze selektiert usw. Die Lautzeit bleibt dann zwar gleich, aber man "sieht" zumindest, dass etwas verarbeitet wird und der Debugger bleibt nicht "ewig" im SELECT-Statement hängen.
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hallo,
vielen Dank, dass solche Statistiken eine Auswirkung haben, war mir nicht (mehr) bewusst. Das kommt davon, wenn man seit über 10 Jahren nur noch programmieren lässt.
Menge ist kein Problem, der Select liefert wegen ZTRACK nie mehr wie 10-15 Einträge. docnum = '0000000000000000' alleine liefert aber aktuell 20Mio.
Meine Inderin hat es angepasst: Sie selektiert ohne docnum und löscht die paar Überflüssigen nachträglich, sollte es auch tun.
vielen Dank, dass solche Statistiken eine Auswirkung haben, war mir nicht (mehr) bewusst. Das kommt davon, wenn man seit über 10 Jahren nur noch programmieren lässt.
OK, dann ist klar, warum er den ungünstigen INDEX nimmt.a-dead-trousers hat geschrieben: ↑28.09.2020 14:51Ganz wichtig für SAP ist die "Spezifizität" oder "Eindeutigkeit" des Index für die Auswahl und dabei haben die sogenannten Datenbankstatistiken eine wichtige Rolle. Je mehr "Einzeldatensätze" pro Index identifiziert werden können, desto eher wird der Index genommen.
In deinem Fall dürfte die Änderung nichts bringen, da die Dokumentnummer(?) mit an Sicherheit grenzender Wahrscheinlichkeit mehr Einzeldatensätze identifizieren kann als der (vermutlich öfter vorkommende) Wert in ZTRACK.
Menge ist kein Problem, der Select liefert wegen ZTRACK nie mehr wie 10-15 Einträge. docnum = '0000000000000000' alleine liefert aber aktuell 20Mio.
Meine Inderin hat es angepasst: Sie selektiert ohne docnum und löscht die paar Überflüssigen nachträglich, sollte es auch tun.
Beitrag
von DeathAndPain (Top Expert / 1944 / 257 /
413
)
»
Ansonsten ist zu erwähnen, dass die Reihenfolge der Parameter im SELECT egal ist. Die Datenbank schaut sich an, was Du alles bietest und sucht sich dann den passenden Index heraus. Das pflegt sehr gut zu funktionieren.
Aber wenn docnum so schlecht ist, dass es 20 Mio Einträge mit derselben docnum gibt, weshalb habt ihr dann auf eurer Datenbank überhaupt einen Index angelegt, der damit anfängt? An eurer Stelle würde ich überlegen, ob ihr den wirklich braucht. Gibt es denn nennenswert Fälle, bei denen ihr nur anhand der docnum sucht?
Es würde auch die Möglichkeit bestehen, einen Index MANDT/ZTRACK/DOCNUM anzulegen. Wenn Du dann in der Datenbank genau mit diesen Feldern suchst, würde es mich sehr wundern, wenn der Datenbankoptimierer ihn nicht nehmen würde. Anscheinend hatten ja schon andere bei euch diese Idee, weswegen ihr bereits mehrere ZTRACK-Indizes habt. Aber natürlich muss jeder weitere Index verwaltet werden, was die Gesamtlast auf der Datenbank erhöht. Wer weiß, vielleicht würde ein Verzicht auf den docnum-Index bewirken, dass einige der ZTRACK-Indizes auch nicht mehr erforderlich sind?
Aber wenn docnum so schlecht ist, dass es 20 Mio Einträge mit derselben docnum gibt, weshalb habt ihr dann auf eurer Datenbank überhaupt einen Index angelegt, der damit anfängt? An eurer Stelle würde ich überlegen, ob ihr den wirklich braucht. Gibt es denn nennenswert Fälle, bei denen ihr nur anhand der docnum sucht?
Es würde auch die Möglichkeit bestehen, einen Index MANDT/ZTRACK/DOCNUM anzulegen. Wenn Du dann in der Datenbank genau mit diesen Feldern suchst, würde es mich sehr wundern, wenn der Datenbankoptimierer ihn nicht nehmen würde. Anscheinend hatten ja schon andere bei euch diese Idee, weswegen ihr bereits mehrere ZTRACK-Indizes habt. Aber natürlich muss jeder weitere Index verwaltet werden, was die Gesamtlast auf der Datenbank erhöht. Wer weiß, vielleicht würde ein Verzicht auf den docnum-Index bewirken, dass einige der ZTRACK-Indizes auch nicht mehr erforderlich sind?
Der Report stellt eine Verknüpfung zwischen IDOC Nummer und Monitoring Eintrag her. Ursprünglich sollten nach Durchlauf des Reports keine Einträge mehr mit docnum = '0000000000000000' existieren, aber inzwischen sind diverse Prozesse dazugekommen, die kein IDOC im SAP erzeugen, aber Einträge für das Monitoring in diese Tabelle schreiben.
Pro IDOC Nummer (>0) gibt es auch nur 5-10 Einträge. Nach IDOC Nummer zu suchen ist durchaus ein sehr häufiger Anwendungsfall.
Pro IDOC Nummer (>0) gibt es auch nur 5-10 Einträge. Nach IDOC Nummer zu suchen ist durchaus ein sehr häufiger Anwendungsfall.
Seite 1 von 1
Vergleichbare Themen
8
Antw.
Antw.
2791
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 3 Tagen von DeathAndPain 4 / 1384
vor 3 Tagen von DeathAndPain 4 / 1384
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 3 Tagen von DeathAndPain 4 / 1384
vor 3 Tagen von DeathAndPain 4 / 1384