SQL-Update mit inner join

[BenderD]

... STRDBG, zum Beispiel.

[Curious]

Ich meinte etwas vergleichbares zu dem folgenden Windows/Linux-Programm

The db2expln tooldescribes the access plan selected for SQL and XQuery statements.Use the tool to obtain a quick explanation of the chosen access planwhen explain data was not captured.

https://www.ibm.com/support/knowledg.../r0005736.html

[Fuerchau]

Im iSeries-Navigator, Menü SQL, und ggf. auch im neuen iSeries-Director.
Bestimmt weiß Birgitta da mehr.

[BenderD]

... da gibt es ein Redbook Query optimization - Google weiß wo. Wobei anzumerken ist, dass die diagnostics im Joblog (bei STRDBG) und der Database Monitor die realen Verhältnisse zur Laufzeit abbilden und Visual explain eher zum Spielzeug gehört, wie db2expln übrigens auch. Das sind reine Schätzungen, die mit den Verhältnissen zur Laufzeit nix zu tun haben müssen. Zur Laufzeit könnte selbst der Ausführungsplan abweichend sein!

D*B

[B.Hauser]

... da gibt es ein Redbook Query optimization - Google weiß wo. Wobei anzumerken ist, dass die diagnostics im Joblog (bei STRDBG) und der Database Monitor die realen Verhältnisse zur Laufzeit abbilden und Visual explain eher zum Spielzeug gehört, wie db2expln übrigens auch. Das sind reine Schätzungen, die mit den Verhältnissen zur Laufzeit nix zu tun haben müssen. Zur Laufzeit könnte selbst der Ausführungsplan abweichend sein!

D*B

ohne REELEN Access Plan kann KEINE Abfrage ausgeführt werden.

Die Access Pläne, die für die Abfragen gespeichert wurden werden im SQL Plan Cache für jede Abfrage hinterlegt (die Dateien haben übrigens genau den gleichen Aufbau wie die Dateien für die Datenbanken-Monitore). Solange kein IPL gefahren ist, kann genau die Abfrage (sogar mit den variablen Werten) und der zugehörige Access Plan mit Visual Explain angezeigt werden. Die Abfrage kann natürlich auch erneut ausgeführt und im Anschluss über Run and Explain mit Visual Explain angezeigt werden.
Gleiches gilt für die Datenbanken Monitore. Alle Informationen sind in Tabellen gesichert und Visual Explain zeigt genau diese Informationen (graphisch! und als Text) an.

Birgitta

[Curious]

@Fuerchau: Cool, danke. Da habe ich den Navigator ja mal wieder total unterschätzt.

@BenderD: Das läuft nach dem Motto "trau keiner Statistik, die Du nicht selbst gefälscht hast". Das ist mir völlig klar. Trotzdem hilft mir das bei der Entwicklung weiter, wenn ich die Schätzung habe. Vielen Dank für die Info. Ich werde mal Google nach dem Redbook fragen.

[Fuerchau]

Also für die Entwicklung verlasse ich mich immer auf die Ausgaben des Debug-Modus.
Die 1. Optimierung kann sehr unterschiedliche ausfallen, wenn das betroffene Volumen trotz identischem SQL jedoch unterschiedlich ist.
Die 2. Abfrage wurd u.U. auch noch mal optimiert, anschließend bleibt aber der ODP auf (immer erst ab der 1. Wiederholung!) und SQL verlässt sich dann auf den Zugriffsplan.

[B.Hauser]

Also für die Entwicklung verlasse ich mich immer auf die Ausgaben des Debug-Modus.
Die 1. Optimierung kann sehr unterschiedliche ausfallen, wenn das betroffene Volumen trotz identischem SQL jedoch unterschiedlich ist.
Die 2. Abfrage wurd u.U. auch noch mal optimiert, anschließend bleibt aber der ODP auf (immer erst ab der 1. Wiederholung!) und SQL verlässt sich dann auf den Zugriffsplan.

1. Die Debug-Nachrichten sind nicht mehr vollständig und zur Analyse nur noch bedingt geeignet.
2. Bei der Optimierung werden sowohl die vorhandenen Zugriffswege (Binary Radix / Encoded Vector Indices, Key Constraints und logische Dateien) als auch die Datenzusammensetzung geprüft. Über den Statistics Manager werden permanent Informationen über die Datenzusammensetzung gesammelt. Bei der Optimierung werden diese Informationen mit berücksichtigt. Deshalb kann die gleiche Abfrage auf unterschiedlichen Maschinen zu unterschiedlichen Access Plans führen und selbst auf der gleichen Maschine können für das gleiche SQL-Statement bis zu 3 Access Pläne gespeichert werden.
Es gibt natürlich noch weitere Kriterien, die das Ergebnis der Optimierung beeinflussen können, anderer Release- oder PTF-Stand, andere Pool/Memory-Größe, Einstellungen in der QAQQINI-Datei etc.
3. Der zeitaufwändigste Part bei der Optimierung ist das Öffnen des Datenpfades.
Beim Öffnen des Datenpfades werden die im Access Plan beschiebenen temporäre Objekte generiert und miteinander verknüpft und dann über die ebenfalls beschriebenen Zugriffsmethoden (Tables Scan, Index Scan, Index Probe) und Indices mit Daten gefüllt. (FULL OPEN).
Da das Öffnen des ODPs zeitaufwändig ist, versucht SQL die Datenpfade offen zuhalten, d.h. damit beim nächsten Durchlauf lediglich die Daten (im ODP) aktualisiert werden müssen (PSEUDO OPEN).
Da jedoch nicht sicher ist, ob eine Abfrage ein One-Shot ist oder nicht, wird der ODP nach der ersten Ausführung (per Default) immer geschlossen.
Wird der ODP gelöscht, z.B. am Ende der Aktivierungsgruppe oder beim Verlassen des Moduls (CLOSQLCSR=*ENDMOD), muss bei jeder Ausführung die volle Optimierung durchlaufen werden.

SQL ist überigens auch lernfähig.
Nach Ausführung jeder Abfragen wird (im Untergrund nochmals) optimiert. Sollte an dieser Stelle festgestellt werden, dass es einen besseren Access Plan gibt (z.B. weil ein neuer Index angelegt wurde), kann der Optimizer bei der nächsten Ausführung (es ist nicht gesagt, dass er muss) den geänderten Access Plan verwenden (AQP = Adapted Query Processing) und damit erneut durch die (volle) Optimierung laufen.

Birgitta