Warum gibt DELETE + REORG keinen Speicherplatz frei (DB2)?

In DB2 habe ich eine Tabelle mit großen Binärdaten. Jetzt habe ich den gesamten Tisch geleert und runstats, reorg, runstats ausgeführt, aber die Menge des belegten Speicherplatzes ändert sich nicht. Was könnte hier falsch sein?

Die Tabelle befindet sich in einem eigenen Tabellenbereich, den ich wie folgt erstellt habe:

CREATE BUFFERPOOL "MY_BP" SIZE 250 AUTOMATIC PAGESIZE 4096;
CREATE LARGE TABLESPACE MY_TBS IN DATABASE PARTITION GROUP IBMDEFAULTGROUP PAGESIZE 4096 MANAGED BY AUTOMATIC STORAGE EXTENTSIZE 64 PREFETCHSIZE 64 BUFFERPOOL MY_BP OVERHEAD 10.500000 TRANSFERRATE 0.140000 FILE SYSTEM CACHING;

Ich habe wie folgt gelöscht / neu angeordnet:

DELETE FROM MY_TBL
RUNSTATS ON TABLE MY_TBL WITH DISTRIBUTION AND DETAILED INDEXES ALL
REORG TABLE MY_TBL
RUNSTATS ON TABLE MY_TABLE WITH DISTRIBUTION AND DETAILED INDEXES ALL
ALTER TABLESPACE MY_TBS REDUCE

Die Tabelle MY_TBL hat davor 2,5 GB belegt und benötigt nach dem Löschen / Reorganisieren nur 3 MB weniger.

FWIW: Ich führe DB2 / NT v9.5.2 aus.

Ich gehe davon aus, dass Sie die automatische Speicherung verwenden. (Nicht, dass dies sonst passieren könnte ... bei der automatischen Speicherung ist dies einfach möglich.)

Das Problem besteht höchstwahrscheinlich darin, dass Ihre Datenbank den Speicherplatz für sich selbst zurückgefordert hat, die Festplatte jedoch nicht an das Betriebssystem zurückgegeben hat. Dies kann sehr einfach gezeigt werden, indem die High Water Mark für den Tablespace überprüft wird.

Führen Sie Folgendes aus

db2 list tablespaces show detail

Dies zeigt Ihnen jeden Tablespace und was er auf der Festplatte verwendet. Used pagesgibt an, wie viele Seiten der Festplatte die Datenbank verwendet. Wenn Sie dies mit total pages(der auf der Festplatte beanspruchten Gesamtsumme) vergleichen, High water mark (pages)wird Ihnen angezeigt, ob Sie mehr "beanspruchen", als Sie tatsächlich benötigen. (dh wenig genutzte Seiten, sehr hohe Gesamtseiten und eine High Water Mark in der Nähe der Gesamtseiten).

Um loszuwerden dieser ungenutzten Speicherplatz aus und senden es an das Betriebssystem das folgende Problem würde (unter dynamischem Speicher): db2 alter tablespace <tablespace name> reduce max. Beispiel

db2 alter tablespace ts1 reduce max;

Dadurch senkt DB2 die High-Water-Marke und gibt die nicht verwendete Platte an das Betriebssystem zurück. (Beachten Sie, dass dies nur für reguläre und große Tabellenbereiche möglich ist, nicht für temporäre System- oder temporäre Benutzertabellenbereiche.)

Wenn Sie DMS ohne automatische Speicherung verwenden, müssen Sie einen etwas anderen Befehlssatz verwenden:

db2 alter tablespace <tablespace name> lower high water mark;
db2 alter tablespace reduce (<containter name> or [all containers] integer K|M|G or integer PERCENT);

Beispiel

db2 alter tablespace ts1 lower high water mark;
db2 alter tablespace reduce (all containers 500 M);

Wo wir arbeiten, fügen wir dies in einige unserer Wartungsskripten ein, sodass wir dies automatisch ausführen, nachdem wir Reorgs durchgeführt haben, um sicherzustellen, dass wir Speicherplatz zurückgewinnen. In unserem Fall verwenden wir DB2 LUW 9.7 FP 4, sodass es nicht schadet, das Information Center für 9.5 zu überprüfen, um sicherzustellen, dass Sie auf die richtigen Informationen für Ihre Version zugreifen können.

BEARBEITEN: Wenn Ihre Tablespaces von einer Datenbank stammen, für die ein Upgrade auf DB2 9.7 durchgeführt wurde, ist möglicherweise das Attribut für wiedergewinnbaren Speicher nicht festgelegt. Dies gilt auch dann, wenn Sie ein Upgrade von DMS auf automatischen Speicher durchführen. In beiden Fällen können Sie die Hochwassermarke nicht wirklich senken. Sie müssen die Tabelle und die Daten ausgeben und die Tablespaces löschen. Erstellen Sie dann den Tablespace mithilfe des automatischen Speichers neu und importieren Sie die Daten für Ihre Tabellen.

Die Tabelle MY_TBLenthält große Binärdaten in einer BLOBSpalte. In der Dokumentation des REORGBefehls heißt es, dass DB2 das Reorganisieren solcher Objekte vermeidet, da dies zeitaufwändig ist und das Clustering nicht verbessert. DB2 kann jedoch gezwungen werden, LOB-Daten neu zu organisieren, wenn die LONGLOBDATAOption angegeben wird. Der nicht verwendete Speicherplatz kann von DB2 wiederverwendet werden. Wenn Sie also neue Daten einfügen, werden zuerst die vorhandenen, nicht verwendeten Seiten gefüllt, bevor neue zugeordnet werden.

Laufen

REORG TABLE MY_TBL LONGLOBDATA

hat den von der leeren Tabelle verwendeten Speicherplatz von 2,5 GB erfolgreich zurückgefordert.

Ich wusste nichts über diese Option und habe sie beim ersten Lesen der Dokumentation überwacht.