View Full Version : SQL - beschleunigen
loeweadolf
16-06-04, 15:25
Als SQL-Anfänger habe ich noch einige Probleme.
Ich habe ein embedded SQL verwendet auf eine
DDS-beschriebene Datei (ca. 500000 Datensätze), aus der nach Vorgaben bestimmte Datensätze mit
DECLARE / SELECT ausgefiltert werden.
Ich habe zwar eine Sortierung (ORDER BY) angegeben,
wäre aber nicht notwendig.
Diese deklarierten Sätze lese ich von vorne bis hinten
durch mit FETCH NEXT, solange bis Fehler-Code 100
auftaucht.
Diverse Datenfelder dieser Sätze werden individuell verändert und jeder dieser Sätze wird zurückgeschrieben mit UPDATE, wobei mit SET die geänderten Felder gefüllt und beschrieben werden, jeweils mit WHERE (Satzindex, bestehend aus mehreren Feldern).
Das Programm läuft ziemlich lange.
Kann es daran liegen, dass kein geeigneter Zugriffspfad vorhanden ist?
Sollte man ein logische erstellen ?
Wonach richtet sich diese, nach den WHERE-Angaben im Update oder nach den ORDER BY im Select ?
Für jede Antwort wäre ich dankvar.
mfg. Ludger
Hallo Ludger,
ob ein Zugriffspfad fehlt, findest Du am einfachsten, wenn Du das Programm im Debug laufen lässt und dann im Joblog nachsiehst; der Query Optimizer legt dort Diagnostics ab, wie er das SQL ausführt.
Bei Deiner Form der Verarbeitung sollte es schneller werden, wenn Du beim Update in der Where Bedingung mit WHERE CURRENT OF Cursorname arbeitest.
mfg
Dieter Bender
Als SQL-Anfänger habe ich noch einige Probleme.
Ich habe ein embedded SQL verwendet auf eine
DDS-beschriebene Datei (ca. 500000 Datensätze), aus der nach Vorgaben bestimmte Datensätze mit
DECLARE / SELECT ausgefiltert werden.
Ich habe zwar eine Sortierung (ORDER BY) angegeben,
wäre aber nicht notwendig.
Diese deklarierten Sätze lese ich von vorne bis hinten
durch mit FETCH NEXT, solange bis Fehler-Code 100
auftaucht.
Diverse Datenfelder dieser Sätze werden individuell verändert und jeder dieser Sätze wird zurückgeschrieben mit UPDATE, wobei mit SET die geänderten Felder gefüllt und beschrieben werden, jeweils mit WHERE (Satzindex, bestehend aus mehreren Feldern).
Das Programm läuft ziemlich lange.
Kann es daran liegen, dass kein geeigneter Zugriffspfad vorhanden ist?
Sollte man ein logische erstellen ?
Wonach richtet sich diese, nach den WHERE-Angaben im Update oder nach den ORDER BY im Select ?
Für jede Antwort wäre ich dankvar.
mfg. Ludger
Die Optimierung geht sowohl von der where- als auch von der order by-Klausel des Select's aus, was für den 2. SQL-Befehl "update ... where" ebenso gilt.
Der Debug-Modus (bzw. QAQQINI-Option) geben im Joblog empfohlene Zugriffspfade aus.
Der "Select ... for update of ..." ist für diesen Fall sicherlich das eleganteste, da auf der aktuelle Tabelleneintrag (Satz) ohne Neupositionierung verwendet wird.
loeweadolf
16-06-04, 17:11
Hallo Dieter, vielen Dank für die Unterstützung.
Aus dem Joblog war erkennbar, dass kein bestender Zugriffspfad nutzbar war.
Ich habe daraufhin ORDER BY ganz rausgenommen, da ich keine Sortierung benötige. Das war allerdings ein Fehler, da dann wohl alle Sätze trotz SELECT-Auswahl genommen werden. Dann habe ich ORDER BY nur mit dem Firmenschlüssel angegeben, für das genügend log. Dateien vorhanden sind.
Beim UPDATE habe ich WHERE CURRENT OF angegeben.
Das beides hatte dann zum Ergebnis, dass bei einer Auswahl von 4800 Datensätzen aus einem Topf von 500000 Sätzen die Verarbeitungszeit von 2 Std. reduziert wurde auf ca. 10 Sekunden. !!
Hallo Baldur,
was bedeuter " Select for update of".
Ist das eine SQL-Anweisung oder nur als Begriff zu verstehen, dass upgedatet wird wie gelesen wird. ?
mfg. Ludger
Hallo Ludger,
Du kannst das jetzt so lassen, das ist ein guter Wert. Normalerweise sollten alle elementaren Zugriffe (lesen Satz pro Datei, Update etc.) im Millisekunden Bereich liegen, je nach Hardware. Alles was signifikant langsamer ist, lässt sich mit einer entsprechenden Analyse schneller machen, je nach Konstellation mit Datenbankmitteln (Index anlegen), Software technisch (so wie bei Dir zum Beispiel) oder oft auch Hardware (Platte, CPU)
Dieter Bender
(der sowas manchmal auch für Geld macht)
Hallo Dieter, vielen Dank für die Unterstützung.
Aus dem Joblog war erkennbar, dass kein bestender Zugriffspfad nutzbar war.
Ich habe daraufhin ORDER BY ganz rausgenommen, da ich keine Sortierung benötige. Das war allerdings ein Fehler, da dann wohl alle Sätze trotz SELECT-Auswahl genommen werden. Dann habe ich ORDER BY nur mit dem Firmenschlüssel angegeben, für das genügend log. Dateien vorhanden sind.
Beim UPDATE habe ich WHERE CURRENT OF angegeben.
Das beides hatte dann zum Ergebnis, dass bei einer Auswahl von 4800 Datensätzen aus einem Topf von 500000 Sätzen die Verarbeitungszeit von 2 Std. reduziert wurde auf ca. 10 Sekunden. !!
Hallo Baldur,
was bedeuter " Select for update of".
Ist das eine SQL-Anweisung oder nur als Begriff zu verstehen, dass upgedatet wird wie gelesen wird. ?
mfg. Ludger
Der fehlende "order by" war sicherlich nicht der Grund, dass du alle Sätze gelesen hast ("order" ist schließlich nur für den Sort und nicht für die Auswahl verantwortlich). Vielleicht hattest du die Where-Klausel gleich mit entfernt ?
update-clause
for update [of column-name, ...]
The UPDATE clause identifies the columns that can be updated in a subsequent positioned UPDATE
statement. Each column-name must be unqualified and must identify a column of the table or view
identified in the first FROM clause of the fullselect. If the UPDATE clause is specified without column
names, all updateable columns of the table or view identified in the first FROM clause of the fullselect are
included. The clause can appear either before or after an accompanying optimize-clause.
The FOR UPDATE OF clause must not be specified if the result table of the fullselect is read-only (for
more information see “DECLARE CURSOR” on page 374), if the FOR READ ONLY clause is used, or if
the SCROLL keyword is specified without the DYNAMIC keyword on the DECLARE CURSOR statement.
Positioned UPDATE statements identifying the cursor associated with a select-statement can update all
updateable columns, if:
v The select-statement does not contain one of the following:
– An UPDATE clause
– A FOR READ ONLY clause
– An ORDER BY clause
v The DECLARE CURSOR statement does not contain a SCROLL keyword without the DYNAMIC
keyword.
The UPDATE clause is a performance option that is not part of ISO/ANSI SQL.
@Baldur ein order by verhindert in jedem Fall einen Full Table scan, es kann also durchaus sein, dass das Weglassen des order by diese Wirkung hat. Im vorliegenden Fall hätte dann eine Fehleinschätzung des Query Optimizers über die Selektivität der Where Klausel vorgelegen, könnte ein Fall für einen Encoded Vector Index sein.
mfg
Dieter