Dlaczego DELETE + REORG wolnego miejsca na dysku (DB2)?

W DB2 mam tabelę zawierającą duże dane binarne. Teraz wyczyściłem cały stół i uruchomiłem komendy runstats, reorg, runstats, ale ilość zajętego miejsca na dysku się nie zmienia. Co może tu być nie tak?

Tabela znajduje się we własnym obszarze tabel, który utworzyłem w następujący sposób:

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;

Usunąłem / poprawiłem w następujący sposób:

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

Tabela MY_TBL zajmowała wcześniej 2,5 GB , a po usunięciu / ponownym zapisaniu zajmuje tylko 3 MB mniej.

FWIW: Używam DB2 / NT v9.5.2.

Zgaduję, że używasz automatycznego przechowywania. (Nie żeby tak się stało inaczej. Po prostu łatwo to zrobić z automatycznym przechowywaniem.)

Problem najprawdopodobniej polega na tym, że baza danych odzyskała miejsce dla siebie, ale nie zwolniła dysku z powrotem do systemu operacyjnego. Można to bardzo łatwo pokazać, sprawdzając znak wysokiej wody dla obszaru tabel.

Wykonaj następujące czynności

db2 list tablespaces show detail

To pokaże każdy obszar tabel i to, czego używa na dysku. Used pagesto ile stron dysku używa baza danych. Porównując to z total pages(całkowitą wartością żądaną na dysku) i High water mark (pages)pokaże, czy „żądasz” więcej, niż faktycznie potrzebujesz. (tj. mało używanych stron, bardzo wysoka liczba stron i znak wysokiej wody blisko wszystkich stron).

Aby pozbyć się tej niewykorzystanej przestrzeni i powrócić do systemu operacyjnego, byś wydać następujące (w automatycznym przechowywania) db2 alter tablespace <tablespace name> reduce max. przykład

db2 alter tablespace ts1 reduce max;

Spowoduje to, że DB2 obniży znak wysokiego poziomu i zwolni nieużywany dysk z powrotem do systemu operacyjnego. (Uwaga: możesz to zrobić tylko w przypadku regularnych i dużych obszarów tabel, a nie systemowych lub tymczasowych obszarów tabel).

Jeśli korzystasz z DMS bez automatycznego przechowywania, musisz użyć nieco innego zestawu poleceń:

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);

przykład

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

Tam, gdzie pracujemy, umieszczamy to w niektórych naszych skryptach konserwacyjnych, aby automatycznie uruchamiać to po przeprowadzeniu ponownych porządków, aby upewnić się, że odzyskamy miejsce na dysku. W naszym przypadku korzystamy z programu DB2 LUW 9.7 FP 4, więc sprawdzenie, czy masz dostęp do odpowiednich informacji dla swojej wersji, nie szkodzi podwójnemu sprawdzeniu Centrum informacyjnego dla wersji 9.5.

EDYCJA: Jeśli obszary tabel pochodzą z bazy danych zaktualizowanej do wersji DB2 9.7, prawdopodobnie nie będzie ustawiony atrybut atrybutu pamięci masowej, który można odzyskać. Dzieje się tak nawet w przypadku uaktualnienia z DMS do automatycznego przechowywania. Tak czy inaczej gryzie, ponieważ nie można obniżyć znaku wysokiej wody. Musisz zrzucić tabelę i dane, upuścić obszary tabel. Następnie ponownie utwórz przestrzeń tabel za pomocą automatycznego przechowywania i zaimportuj dane do swoich tabel.

Tabela MY_TBLzawiera duże dane binarne w BLOBkolumnie. Dokumentacja REORGpolecenia mówi, że DB2 unika reorganizacji takich obiektów, ponieważ jest to czasochłonne i nie poprawia klastrowania. Jednak DB2 może zostać zmuszony do reorganizacji danych LOB, jeśli LONGLOBDATAzostanie podana opcja. Niewykorzystana przestrzeń może być ponownie wykorzystana przez DB2, więc wstawienie nowych danych najpierw wypełni istniejące, nieużywane strony przed przydzieleniem nowej.

Bieganie

REORG TABLE MY_TBL LONGLOBDATA

pomyślnie odzyskano 2,5 GB miejsca na dysku, z którego korzystała pusta tabela.

Nie wiedziałem o tej opcji i nadzorowałem ją przy pierwszym czytaniu dokumentacji.