Space-Frage bei Delete/Insert

Da muss ich einfach mal nachfragen:

– ist der Tablespace mit COMPRESS YES definiert ?
– sind VARCHAR – Spalten in der "Arbeitstabelle" ?
– hat die "Arbeitstabelle" einen expliziten CLUSTERING INDEX ?
– Ist das DB2-System Bestandteil eines Sysplexes ?

ok.

Wenn die Tabelle mit COMPRESS YES definiert ist, kann dies der Grund sein, warum weniger Platz  benötigt wird, als Zeilenlänge * Zeilenanzahl.  Durch die Komprimierung wird für das Abspeichern einfach weniger physischer Platz benötigt.
( Der eingesparte Platz kann dabei durchaus auch 80% betragen ).

DB2 könnte bei Segmented TS den Platz von gelöschten Elementen wiederverwenden wenn:
a) der neue Satz in diese Page gehört
—> aufgrund des Clustering Index versucht DB2 beim INSERT, die Schlüsselfolge einzuhalten

b) der neue Satz da reinpasst
—> es ist COMPRESS YES definiert, d.h. der neue Satz kann (physisch) länger sein als der gelöschte, und dann passt er nicht in die Lücke

Nein, es macht hier keinen Unterschied zwischen SegSize 4 und 32. ( ausser bei Verwendung von SYSPLEX -da spielt es eine Rolle )

Ups, sorry – ich hatte die Extent-Frage andersherum gelesen. – mein Fehler -.

Ein Compression Dictionary wird für den kompletten Tablespace gebildet, also in diesem Fall aus dem Inhalt der beiden statischen Tabellen.

Wenn der Tablespace das nächste mal so aufgebläht ist, dann könntest Du mal die Space-map-page ausdrucken ( mit DSN1PRNT ) und schauen, wieviele pages pro segment überhaupt verwendet wurden.
Aber so ein Phänomen kenne ich selbst nur bei einem Sysplex-Verbund.

Ja, es ist durchaus möglich, dass pro Segment nur ein einziger Satz drin steht.

So einen Fall hatten wir auch mal
-> Work-Tabelle -> viele Inserts/Deletes -> regelmässig 251 Extents  obwohl effektiv nur 10 Sätze drinstanden
-> nach Reorg wieder 1 Extent.

Auf die Lösung ( war ein Data-Sharing Problem ) bin ich damals auch erst nach DSN1PRNT und Analyse der Physik gekommen.

fehlende COMMITs sollten eigentlich keine Rolle spielen. ( Für dieses Problem, natürlich sollte man … )

mal so als Experiment ( zum Ausschluss gewisser Faktoren): Leg doch mal den Index ohne explizites Cluster-Attribut an.

Wird diese Arbeitstabelle nur von diesem Programm benutzt und ist sie anschliessend wieder leer, solltest Du die Verwendung von DECLARED TEMPORARY TABLES in Betracht ziehen.

Hi Alexander,

zu meinem Verständnis: wie ist denn das Verhältnis zwischen Inserts und Deletes – 5:1, 50:1 oder 500:1?

Wozu wird überhaupt ein Index benötigt, wenn nur Inserts und Deletes (in einem sequentiellen Lauf?) stattfinden?

Handelt es sich um eine "temporäre" Tabelle, die in einem Programmlauf gefüllt und geleert wird?

@Ulrich Mayer: Wenn kein Data Sharing betrieben wird, warum sollten dann die Segmente nur wenig gefüllt werden?

MfG

AxelP