Platten müllen sich voll

[Xanas]

Also das Ptf haben wir und der Status ist ersetzt.

[TARASIK]

Hallo Xanas,
also dieses SI16092 wurde zuletzt ersetzt durch SI18421 und ein MF35462 auf 5722999.
Aber generell würde ich nochmals suchen mit dem Tip von mir
mit dem Suchstring.
Es gibt zudem ein neues Cumtape C5207530.

[pwrdwnsys]

Hallo Xanas,
dann halt so:

http://www-912.ibm.com

und als Suchstring:temporary storage r530

zum Beispiel

Lass doch mal (im Batch) den Befehl RTVDSKINF laufen. Dauert ggf. 1...2h. Anschliessend mit PRTDSKINF erst mal die Bibliotheken nach Größe prüfen und dann die größten Objekten drucken lassen. Die Journalempfänger vom QAUDJRN sind auch immer ein guter Platzfresser, wenn viel protokolliert wird. Nicht zuletzt die QHST*-Objekte.

K.

[Xanas]

Danke euch/Ihnen allen für die vielen Tips. Wir haben auch noch den ein oder andernen Speicherfresser auf Grund der Hinweise gefunden.

Nur trozdem wächst der Temporäre Speicher täglich um ca. 700 MB. Wir haben einige SQL Programme getestet und die lassen immer was hängen.

Also nach 3-4 Monaten ohne IPL wäre die I5 tot, kann man da SQL technich nichts machen?

[pwrdwnsys]

Danke euch/Ihnen allen für die vielen Tips. Wir haben auch noch den ein oder andernen Speicherfresser auf Grund der Hinweise gefunden.

Nur trozdem wächst der Temporäre Speicher täglich um ca. 700 MB. Wir haben einige SQL Programme getestet und die lassen immer was hängen.

Also nach 3-4 Monaten ohne IPL wäre die I5 tot, kann man da SQL technich nichts machen?

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.

[B.Hauser]

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