Hermann hat geschrieben:Am einfachsten vermutlich über einen SQL-Trace. Transaktion ST05, SQL-Trace einschalten, Transaktion ausführen, dann in ST05 Trace ausschalten und anzeigen. Man sieht dann auf welche Tabellen zugegriffen wurde.
Und man kann aus dem Trace auch gleich in den Quelltext zur entsprechenden Anweisung springen ...
Für gepufferte Tabellen findest Du im Trace aber keine lesenden Zugriffe mehr, wenn zuvor schon mal die Einträge gelesen worden sind.
Abhilfe schafft das Löschen der Tabellenpuffer.
(Das darf nicht jeder, sollte im Produktiv-System gar nicht und auch in Test-Systemen nicht ohne Rücksprache mit sonst noch am System arbeitenden erfolgen.)
Bei Zugriffen auf Cluster-Tabellen siehst Du im SQL-Trace nur den Namen der SQL-Tabelle, die die DB kennt (also z.B. RFBLG statt BSEG oder CDCLS statt CDPOS).
Bei Zugriffen auf Pool-Tabellen (wenn die nicht sowieso schon gepuffert sind) siehst Du den R/3-Tabellennamen auch nur in der WHERE-Klausel, also z.B. ein SELECT auf ATAB mit WHERE TABNAME = T... AND TABKEY = ...
Andere Alternativen wären SE30 (Performance trace) mit entsprechenden Einstellungen oder Debuggen mit Break-Point auf Anweisung SELECT (kann aber für komplexe Transaktionen recht mühsam werden).
Die vierte Möglichkeit wäre Programm RSABAPSC zur statischen Quelltext-Analyse.
Aber erstens kann das Programm prinzipiell dynamische Aufrufe nicht weiterverfolgen, zweitens enthält es diverse Bugs, für die sich SAP seit Jahren nicht interessiert.
Da helfen dann nur noch eigene Tools weiter.
Die Probleme mit der Pufferung hat man beim SQL-Trace natürlich nicht, wenn man sich für die in einer Transaktion geänderten DB-Tabelleneinträge interessiert.
Aber auch hier sollte man möglichst nicht noch mehrere Batch Jobs parallel im Hintergrund laufen haben.
Und wenn man nur wissen will, womit ein länger laufender (BTC-)Prozess gerade beschäftigt ist, hift auch die SM50 (bzw. SM51/SM66) ein wenig weiter.