Zitat Zitat von pwrdwnsys
Was läßt SQL denn da hängen? Maximal doch gelöschte Sätze in den Tabellen. Und die lassen sich mit RGZPFM [Dateiname] beseitigen. Durch einen IPL geht das nicht weg. Es sei denn die Journale laufen zu. Dann werden die bei IPL umgehängt und -je nach Parameter- die alten Receiver gelöscht.
Wird keine COMMIT-Steuerung verwendet, kann man auch den Parameter REUSEDLT(*YES) im CRTPF oder CHGPF verwenden. Allerdings ist das Schreiben in die Tabellen langsamer.
U.A. werden Access Plans gespeichert. Bei Embedded SQL direkt im Programm-Objekt. Nicht mehr benötigte Access Plans werden nicht gelöscht, so dass ein Programm ohne Änderung aufgrund der geänderten Datenkonstellation über die Zeit wachsen kann. Das Geiche geschieht, wenn SQL Packages verwendet werden. Da hilft nur die Programme bzw. die SQL Packages neu zu erstellen. Aber das kann nicht der Grund für Dein Problem sein, da nach IPL wieder alles beim alten ist.

Wenn mit der neuen SQL Query Engine gearbeitet wird, werden Access Plans zusätzlich in einem systemweiten Plan-Cache gespeichert, um den Overhead zum Ermitteln des optimalen Zugriffs-Weges durch den Query Optimizer zu reduzieren. Für jede SQL-Abfrage können bis zu 3 unterschiedliche Access Plans gespeichert werden, wobei gleiche Abfragen auch die gleichen Access Plans verwenden können. Dieses Plan-Cache wird beim IPL gelöscht!

Wenn Ihr also sehr viele SQL-Abfragen habt, könnte damit schon die Platte vollgeschrieben werden. (Ich habe allerdings keine Anhalts-Punkte wie mächtig dieser Plan-Cache werden kann). Wird mit der klassischen Query-Engine gearbeitet, wird der Plan-Cache nicht verwendet. Ob mit der CQE oder SQE gearbeitet wird, entscheidet der Query-Dispatcher.

Es gibt allerdings Möglichkeiten zu vermeiden, dass die SQE verwendet wird. z.B. wenn auf einer physichen Datei eine logische Datei mit SELECT/OMIT-Anweisungen liegt wird immer die CQE verwendet.

Wird keine COMMIT-Steuerung verwendet, kann man auch den Parameter REUSEDLT(*YES) im CRTPF oder CHGPF verwenden. Allerdings ist das Schreiben in die Tabellen langsamer
Das ist nur die halbe Wahrheit, so ist z.B. beim Einsatz von DDS beschriebenen Dateien das Lesen wesentlich langsamer als bei SQL beschriebenen Dateien. Der Grund liegt darin, dass bei DDS beschriebenen Dateien die Data-Validation beim Lesen gemacht wird, während sie bei SQL beschriebenen Tabellen erst beim Update bzw. Write erfolgt.

Werden einzelne Sätze geschrieben, ist das Schreiben mit Dateien, die mit REUSEDLT(*YES) definiert sind langsamer. Werden aber Blöcke geschrieben, ist das Schreiben sogar minimal schneller als mit REUSEDLT(*NO). Der Grund hierfür ist der sogenannte Concurrent Write Support. Dabei werden zunächst die relativen Satz-Nr. ermittelt und Speicher reserviert und erst dann wird physich geschrieben. Bei REUSEDLT(*NO) kann immer nur ein Satz nach dem anderen geschrieben werden.

Birgitta