SQL-Update mit inner join

[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