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

18

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.

db2 maintenance database-size db2-luw size Alexander Tobias Bockstaller
źródło
Czy to działa w systemach na db2 v8?
Tony

Odpowiedzi:

22

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.

Chris Aldrich
źródło
+1 - dobrze widzieć, jak ekspert DB2 uczestniczy w tworzeniu witryny. W przeszłości byliśmy słabi w tej dziedzinie.
Philᵀᴹ
1
Krótki komentarz, w programie DB2 9.5 nie można używać składni alter tablespace <tbsp> lower high watermarklub alter tablespace <tbsp> reduce max- nie zostały one wprowadzone do wersji DB2 9.7.
Ian Bjorhovde
Jak wspomniałem w moim pierwszym poście, próbowałem już większości tego i nie wyszło. Do tej pory znalazłem rozwiązanie samodzielnie: nie można odzyskać miejsca na dysku, ponieważ nie określiłem opcji LONGLOBDATA, co wydaje się konieczne, jeśli chcesz odzyskać miejsce na dysku z obiektów BLOB lub CLOB. Proszę zobaczyć moją odpowiedź na moje pytanie tutaj. W każdym razie doceniam wysiłek włożony w twoją odpowiedź, +1!
Alexander Tobias Bockstaller
9

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.

Alexander Tobias Bockstaller
źródło
Słuszna uwaga. Jednak z tego, czego właśnie nauczyłem się w odcinku DB2NightShow „Attack of the Blob”, nie chcesz zbyt często uruchamiać opcji LONGLOBDATA, ponieważ zajmuje to więcej czasu i / lub powoduje problemy z wydajnością (jeśli próbujesz wykonać REORG online) .
Chris Aldrich,
Bazy danych, z którymi mamy do czynienia, zawierają dane dziennika z maszyn przemysłowych. Kwerendy dotyczące takich baz danych nie są krytyczne pod względem czasu, więc jeśli wydajność spadnie podczas ponownego porządkowania, nie stanowi to problemu.
Alexander Tobias Bockstaller