Partitionierung von Tabellen / Anlegen von Extends
- Dieses Thema hat 5 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 12 Jahre, 4 Monaten vonMitglied.
- AuthorPosts
- 30. September 2010 um 5:21 Uhr #4097
Problem: wir haben eine DB2-Table, in die bei Batch-Verarbeitungen Millionen von Sätzen (unterschiedklicher Ausprägungen) geschrieben werden, die dann entladen werden und an mehrere Fremdsysteme übertragen werden. Die Tabelle wird dann vorübergehend sehr groß, jede Menge Extends werden angelegt.
Nach der Übertragung wurden die Sätze bisher per SQL (DELETE FROM XX where XY = XZ) gelöscht, die Dateien werden wieder freigegeben.
Um das zu optimieren( langsam, Lock Escalation-Meldungen), wurde die Tabelle partitioniert und der DELETE per Leerload Partitionweise implementiert.
Funktioniert auch bestens aber:
Es gibt jetzt das Problem, das wir nicht mehr ausreichend Extends anlegen können, da das DB2 ja intern wohl irgendwie die Extends als "quasi-partitions" anlegt, was ja nun nicht mehr geht.
Daher müssen die TS-Primary-Größen leider extrem groß ausfallen.
Was kann man(n) da tun, gibt es wirklich keine Möglichkeit, das zu umgehen ?30. September 2010 um 9:40 Uhr #4251Hallo Rodi!
Für das Löschen großer Datenmengen steht, wie von Dir "Leerload" genannt der LOAD (DD DSN=) NULLFILE zur Verfügung und seit DB2 V9 auch das TRUNCATE Statement.
Wenn man möchte, dass der bisher allokierte Speicherplatz unverändert erhalten bleibt, dann sollte der LOAD und REORG mit der REUSE Option erfolgen. (Die Extents werden aber dadurch eben gerade nicht abgebaut!)
Die REUSE Option sollte weggelassen werden, wenn der Platz völlig neu angelegt werden soll. Dann müssen aber auch die Table-/Indexspace Größen PQTY und SQTY korrekt – also ausreichend groß – definiert sein. Ggf. müssen die Größen mit ALTER angepasst werden.
Der REORG mit der REBALANCE Option hilft die vorhandene Datenmenge gleichmäßig auf die Partitions zu verteilen.
Die Angabe VOLATILE erinnert den Optimizer daran, dass der Inhalt/Umfang einer Tabelle häufigen Schwankungen unterliegt.
Die BIND Option REOPT(ALWAYS) sorgt bei Packages dafür, dass neue Objekt-Eigenschaften vor jeder Ausführung für die Zugriffspfadbestimmung berücksichtigt werden.
Viele Grüße
Gernot30. September 2010 um 10:18 Uhr #4364Da 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). Und deshalb müssen die Tablespaces so riesengroß angelegt werden. So die Auskunft unserer DBA´s.
Das kann ich irgendwie nicht glauben.30. September 2010 um 12:01 Uhr #4444Ähm,
eigentlich kann ich meiner ersten Anwort nur noch einen Aspekt hinzufügen: Dann müssen halt mehr Partitions angelegt werden. Alles andere ist gesagt.
Zur Klärung wirklich aller Fragen und Hintergründe kann ich nur das von mir publizierte Dokument "DB2 VSAM Cluster Managemet" empfehlen. Du findest es unter https://ruban.de/DB2_for_z_OS/DB2_z_OS_Papers/db2_z_os_papers.html.
Gruß
Gernot30. September 2010 um 16:18 Uhr #4488223F34396660500 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.5. Oktober 2010 um 6:11 Uhr #4514Ich bedanke mich für die Antworten. Die Arbeit hätte ich mir und euch wahrscheinlich sparen können, hätte ich richtig gelesen. Mein Bestreben war es eigentlich, jede Menge Daten in eine Partition zu bekommen ohne aber den Platz dafür ständig vorhalten zu müssen. Leider geht das aber nicht, da ich ja mit dem DSSIZE-Parameter die MAXIMAL- (und nicht Mindest- oder Start-) Größe einer TS-Partition vorher festlegen muss. Ich habe das mal mit verschiedenen Parametern ausprobiert und es ist natürlich tatsächlich so, das Extends angelegt werden; aber jeweils (natürlich) nur bis zur im CREATE-TS angegebenen DSSSIZE. Aber wieder was gelernt !!
Wir heben die Partitionierung jetzt wieder auf und trennen die Tabelle statt in Partitions in einzelne Tabellen. Damit benötigen wir den Platz nur temporär und sind auch beim löschen mit einem Leerload schnell. - AuthorPosts
You must be logged in to reply to this topic.
