Probleme mit View RECORD_LOCK_INFO

[Fuerchau]

"Damit erübrigt sich wohl auch irgendwelche temporären Tabellen zu erstellen."
Klar, wenn man seine Anforderungen nicht überprüft.

SQL ist eine Massenverarbeitung die ausschließlich von Indizes lebt.
Nur dann ist SQL schnell.
Nun liegt es in der Natur der Sache, dass Table-Function keinen Index bieten und SQL somit gezwungen ist, sämtliche Informationen zu lesen, und das dauert, da auch der Aufruf von API's mit allem Drum und Dran (USRSPC-Verarbeitung) eben aufwändig ist.

Wenn ich aber eine bestimmte Information suche, ist ist durchaus sinnvoll, in Teilergebnissen zu denken.
Bei der Verwendung von SQL wird gerne die gute alte Tradition des logischen Denkens vernächlässgt. Denn dazu gehört es eben, sich über Zugriffe vorher gedanken zu machen.

Wenn ich also die Aufgabe betrachte, so stehen da letztlich 3 API-Views zur Verfügung.
1. Job's um auf die/den Jobs einzuschränken, der auf LOCKW steht.
Damit reduziert sich bereits im 2. Schritt, die Anzahl der zu prüfenden Job-Satzsperren.

2. Mit diesen wenigen Jobs (im Zweifel meist nur 1), ermittle ich nun die Objekte, of die diese Jobs warten. Da kommt je Job immer nur 1 Objekt heraus (ausßer bei Multithreading bei z.B. Java).

3. mit diesen wenigen Objekten (im Zweifel meist nun auch nur noch 1) schaue ich nun, welche Jobs wiederum genau dieses Objekt im Zugriff haben um letztlich Job, Objekt und Satznummer zu erhalten.

Baue ich alles in einen großen SQL, zwinge ich ja SQL dazu alle Informationen zu ermitteln, also auch die, die ich gar nicht benötige (z.B. tote Jobs), um mir letztlich das selbe Ergebnis zu liefern, dass ich durch Zerlegung in Einzelschritte erreiche.

Wenn du auf temporäre Tabellen verzichten möchtest, kann man das natürlich auch ausprogrammieren (Declare/Open/Fetch/Close, Schleifen, Compilieren, Testen, korrigieren).
Mit temporären Tabellen kann ich die Zwischenergebnisse einfacher verifizieren und ggf. dann per Joins aus den Zwischenergebnissen auf die Tablefunctions weitermachen.
Wenn dann alles klar ist, kann ich das auch noch in eine SRCPF packen und per RUNSQL einfach ausführen.

Dieses Verfahren (das hat mit Table-Functions wenig zu tun), wende ich sehr häufig an, da SQL mir zu oft auch trotz Indizes einfach zu lange braucht. Erst wenn ich die Aufgabe, so wie früher;-), in Einzelschritte zerlege, komme ich von Minutenlaufzeiten auf Sekunden.

[Fuerchau]

Nun habe ich mir die Views mal auf einem V7R3-System angeshen.
Leider ghen diese Views nicht vom Job, sondern von den Objekten aus.
Somit ist eine performante Abfrage aus diesen Views leider nicht möglich.

Aber es hindert euch ja nicht, aus den bekannten API's TABLE-Funtions zu schreiben, die die fehlenden JOB-Informationen (welche Objekte in Benutzung sind) zu schreiben.

Leider geht auch dei RECORD_LOCK_INFO von den Objekten und nicht von den Job's aus.
Somit werden alle Objekt ausgewertet, also auch solche, die derzeit in keinem Job verwendet werden.

Um also obige Aufgabe performant zu lösen, muss man hier leider die klassischen API's verwenden.

https://www.ibm.com/support/knowledg...s/qdbrjbrl.htm
https://www.ibm.com/support/knowledg...s/qwcrlcki.htm