ich hoffe auf Hilfe bei meinem Problem; Performance-Probleme wurden sicher schon des Öfteren behandelt, aber ich habe aus meiner Sicht so ziemlich alles versucht was machbar ist.
Generell geht es darum, dass ich aus einer Tabelle DSWP_BPM_ALERTS (Business Process Monitoring alerts) Werte in eine interne Tabelle selektiere; dies klappt soweit auch ohne Probleme:
select * from DSWP_BPM_ALERTS into TABLE it_bpm_alerts where
DSWP_BPM_ALERTS~ADATE in so_date and
DSWP_BPM_ALERTS~alert in so_alert and
DSWP_BPM_ALERTS~sessno in so_sess and
DSWP_BPM_ALERTS~sid in so_sid.
Anschließend wird ein Loop über die interne Tabelle ausgeführt und mittels des Aufrufs einer Klasse werden zusätzliche Daten ermittelt und in die Ergebnistabelle
geschrieben:
Ich habe hier auch einmal eine Laufzeitanalyse mit der Transaktion SAT durchgeführt und das Ergebnis war, dass die Datenbank für 99% der sehr langen Laufzeit erforderlich ist; bei einer Einschränkung auf ca. 1200 Datensätze dauert es ca. 20 Minuten bis die Auswertung abgeschlossen ist und das Ergebnis in der ALV-Liste angezeigt wird. Man kann sich vorstellen wie lange es dauert wenn es 10x so viele Datensätze sind.
Ich habe aus der Laufzeitanalyse den Eindruck gewonnen, dass die Klassenschnittstelle CL_AGS_BPM_OPERATIONS=>GET_ALERTTYPE_CONTEXT für die überlange Laufzeit verantwortlich ist und sehe hier nur wenig Optimierungspotential.
Ich habe im Programmcode selbst versucht die Auswertung zu beschleunigen indem ich bspw. ein Feldsymbol anstelle der work-area verwendet habe, aber die Laufzeit hat sich dadurch kaum verbessert.
Vielleicht sehe ich gerade den Wald vor lauter Bäumen nicht; ich bin jedenfalls für jede Hilfe dankbar.
Mach z.B. mit der ST05 einen SQL-Trace und schau dir an welche Tabellen die Methode CL_AGS_BPM_OPERATIONS=>GET_ALERTTYPE_CONTEXT abfragt. Eventuell kannst du ja auch das Ergebnis der SAT verwenden und nur die Tabellen prüfen welche die meiste (verdichtete) Laufzeit verbrauchen.
Direkt in der ST05 kannst du dir dann das Ergebnis und den Ausführungsplan der Query anzeigen lassen. Da kannst du dann sehen, dass vermutlich ein "Full Table Scan" ausgeführt wird. Das ist für so ziemlich jede Datenbank der Super-Gau. Wenn das der Fall ist, solltest du für die betroffenen Tabellen einen Tabellenindex (im Z-Namensraum) anlegen der möglichst viele Felder deiner Abfrage enthält. Damit sollten sich solche "Langläufer" um den Faktor 10 verringern lassen.
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.
Ansonsten gilt auch der Grundsatz, dass SAP-Methoden und Funktionsbausteine immer langsam sind, da sie viel mehr Daten ermitteln, als man tatsächlich braucht (siehe Dein READ TABLE INDEX 1) und das auch noch ineffizient. Von daher kannst Du auch schauen, ob Du die Methode nicht weglassen und die benötigten Daten selbst per SELECT direkt aus der Datenbank lesen kannst. Häufig ist das mit einem Bruchteil der Laufzeit möglich. Dabei kann auch wieder die von adt erwähnte ST05 hilfreich sein, da Du dort siehst, was die SAP liest. So findest Du die benötigten Datenbanktabellen und -spalten und kannst den Zugriff für Deine Zwecke optimieren und selbst ausführen.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag: Legxis
Bei Performance-Problemen mit SAP-Standard-Coding lohnt eigentlich immer eine Suche nach entsprechenden SAP Notes.
Bei der Suche nach "CL_AGS_BPM_OPERATIONS=>GET_ALERTTYPE_CONTEXT" werden auch gleich zwei Notes genannt, die ggfs. interessant sein könnten. Allerdings betreffen beide Solman 710.
Gerade für Komonente ST hat man häufig den Eindruck, da wird vieles schnell hingeschmuddelt und entsprechen häufig gibt dann Korrekturen via SAP Note.
Folgende Benutzer bedankten sich beim Autor zzcpak für den Beitrag: Legxis
Ich habe mit Hilfe eurer Tips die Performance deutlich verbessern können.
Es ist gegenwärtig noch etwas geplant, was die Performance evtl. noch etwas steigert.
Nach Abschluß der Arbeiten werde ich meinen Lösungsweg hier vorstellen.