SQL Performance

[BenderD]

wobei die zeitlichen Größenordnungen verschiedener Effekte sehr unterschiedlich sind (folgend ein paar meiner Erfahrungswerte, nicht ohne Bauch):

Syntaxcheck: millisekunden
Optimizer: hundertstel bis zehntel Sekunden
ODP Neuerstellung: bei vorhandenem Index milli sec
ODP Neuerstellung: bei erstelltem Index siehe temp Index
Open Close bei vorhandem Zugriffsweg unter der Messbarkeit
Hard Close: millisec (wird fast nur bei disconnect wirksam und da immer)

full Table scan: pro Satz sub millisec mal Anzahl der Sätze (können Minuten und mehr sein)
Index Aufbau ohne Mitbenutzung: > full Table scan
Index Aufbau mit Mitbenutzung: << full Table scan

mfg

Dieter Bender

wie Dieter schon sagt, die Hinweise sind dürftig.
Aber ...

Dynamisches SQL ist grundsätzlich nicht die beste Lösung. Besonders dann nicht, wenn das gleiche SQL-Statements mehrfach nur mit unterschiedlichen Variablen-Werten aufbereitet wird.

Damit nimmst Du dem Optimizer jegliche Möglichkeit einen einmal erstelleten Daten Pfad (ODP) wiederzuverwenden. Das heißt bei jeder Ausführung muss nicht nur die komplette Optimierung ausgeführt werden, sondern es muss zusätzlich noch eine Syntax-Prüfung des Strings und eine Konvertierung des Strings in ein ausführbares SQL-Statement erfolgen.

Die Optimierung als solches ist der zeitaufwändigste Prozess bei der ganzen Ausführung:

• Ein Access Plan muss gebildet, oder zumindest validiert werden. Bei statischem SQL wird der letzte Access Plan im Programm-Objekt selber gespeichert und kann mit PRTSQLINF angezeigt werden. Bei erneuter Ausführung kann dieser Access Plan geprüft werden. Bei dynamischem SQL werden keine Access Plans im Programm-Objekt gespeichert, d.h. sofern die Ausführung nicht mit der SQL Query Engine (SQE) erfolgt, bei der Access Plans im systemweiten SQE Plan Cache gespeichert werden und damit validiert werden kann, muss der Access Plan bei jeder Ausführung komplett neu gebildet werden:
  
  • das SQL-Statement muss analysiert und
  • gegebenenfalls umgeschrieben werden,
  • alle Zugriffswege müssen bewertet werden,
  • es muss entschieden werden ob und welche temporären Objekte (z.B. Hash Tables, relative record Listen, Indices, Datenstrukturen ...) gebildet werden müssen.
• Erst nachdem ein aktueller Access Plan vorliegt, kann der Datenpfad geöffnet werden, d.h. die temporären Objekte werden gebildet und mit Hilfe der im Access Plan festgelegten Zugriffswege mit Daten gefüllt.

Nach der ersten Ausführung eines SQL Statements wird der ODP immer wieder komplett gelöscht. War der ODP wiederverwendbar, wird beim zweiten Durchlauf der im Job Cache gesicherte Access Plan validiert und der ODP erneut geöffnet. Nach dem zweiten Durchlauf bleibt der ODP geöffnet, d.h. bei der Ausführung des OPEN-Befehls werden lediglich die Daten in den temporären Objekten aktualisiert.

Achtung: Man sollte die Option CLOSQLCSR (im Compile Command) nicht verändern. Der Default-Wert ist *ENDACTGRP, d.h. der full close, also das Löschen des ODPs erfolgt mit Beendigung der Aktivierungsgruppe. Solange die Aktivierungsgruppe geöffnet ist, kann ein ODP wiederverwendet werden. Bei der Option *ENDMOD, wird der ODP komplett gelöscht, sobald die Ausführung des Moduls beendet wurde. Damit muss bei jedem Durchlauf ein FULL OPEN, also die komplette Optimierung erfolgen.

Übrigens: Auch das Ändern der Bibliotheksliste führt bei unqualifizierten Zugriffen auf physische Dateien/Tabellen mittels SQL zu einem Hard Close der ODPs.

Birgitta