Forum

223F34396660500 wrote: Da habe ich mich wohl missverständlich ausgedrückt: Meine eigentliches Problem ist, das während des Füllens der Tabelle durch das Anwendungsprogramm (angeblich) keine Extends mehr angelegt werden können (da das DB2 die Extends wie Partitions behandelt und das bei Partitioned Tables nicht funktioniert).

Da werden jetzt wohl verschiedene Begriffe verwurstelt.

Bei einem Extent wird eine einzelne VSAM-Datei vergrössert. Das kann bis zu ca. 250 mal pro VSAM-Datei erfolgen und bis die physische Maximalgrenze einer VSAM-Datei erreicht ist.
diese Grenze lag früher mal bei 2 GB. Wurde sie erreicht, hat DB2 eine neue VSAM-Datei ( mit der "laufenden Nummer" 2 ) angelegt und den Tablespace auf diese Weise weiter vergrössert.

Bei einem partitioned tablespace wird diese "laufende Nummer" zum Speichern der Partitionsnummer verwendet.
Daher kann bei Platzmangel DB2 den oben genannten Mechanismus ("Hinzufügen eines weiteren VSAM-Clusters mit der laufenden Nummer n+1") nicht verwenden. Der einzelne VSAM-Cluster kann aber trotzdem seine 250 Extents machen.

Ein einzelner VSAM-Cluster kann inzwischen 64 GB gross werden. Ein PRIQTY 270000 SECQTY 270000 würde dafür genügen ( wobei mit SECQTY -1 die sekundäre Allokation nicht fix ist sondern mit dem Speicherbedarf wächst. Also ein PRIQTY 72000 SECQTY -1 würde Dich primär 100 Cylinder kosten und Du könntest vermutlich trotzdem die 64 GB voll ausnutzen ).

Bei REBALANCE musst Du aufpassen, weil DB2 dann die Partitionsgrenzen selbständig ändert und Dein Laden mit NULLFILE vermutlich falsche Daten löscht.   

Bei so einem Massendelete würde ich ausserdem empfehlen, vorher einen LOCK TABLE … IN EXCLUSIVE MODE abzusetzen. Das erspart Dir nicht nur die Lockescalation, sondern auch vorher die ganzen Locks auf Page-Ebene.
Zusätzlich werden natürlich die ganzen Daten beim Löschen aufs Logband geschrieben. Ggf ist zu prüfen, ob der Tablespace nicht auf NOT LOGGED gesetzt werden kann.