Чому DELETE + REORG не вільний диск (DB2)?

У DB2 у мене є таблиця, що містить великі двійкові дані. Тепер я очистив всю таблицю і запустив runtats, reorg, runtats, але кількість місця на диску не змінюється. Що може бути тут не так?

Таблиця знаходиться у власному просторі таблиць, який я створив так:

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;

Я видалив / перезаписав наступним чином:

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

Таблиця MY_TBL займала 2,5 Гб раніше всього, а після видалення / перезапису використовується лише на 3 Мб менше.

FWIW: Я запускаю DB2 / NT v9.5.2.

Я буду гадати, що ви використовуєте автоматичне зберігання. (Не те, щоб це могло статися інакше ... це просто легко зробити за допомогою автоматичного зберігання.)

Проблема, швидше за все, у тому, що ваша база даних відновила простір для себе, але не випустила диск назад в операційну систему. Це можна легко показати, перевіривши високу марку води для простору таблиць.

Виконайте наступне

db2 list tablespaces show detail

Це покаже вам кожен простір таблиць і що він використовує на диску. Used pages- скільки сторінок диска використовує база даних. Порівнюючи це проти total pages(загальна сума заявлених на диску) і High water mark (pages)заповіт, ви покажете, якщо ви "вимагаєте" більше, ніж вам потрібно. (тобто низько використовуваних сторінок, дуже високих загальних сторінок та високої позначки води, близької до загальної кількості сторінок).

Для того, щоб позбутися від цього невикористаного простору і повернути його в операційну систему ви б випустити наступне (під автоматичним зберігання): db2 alter tablespace <tablespace name> reduce max. приклад

db2 alter tablespace ts1 reduce max;

Це призведе до того, що DB2 знизить мітку високої води і відпустить невикористаний диск назад в операційну систему. (Зверніть увагу, ви можете це робити лише для звичайних і великих табличних просторів, а не для тимчасових системних або тимчасових просторів користувачів).

Якщо ви використовуєте DMS без автоматичного зберігання, вам потрібно використовувати дещо інший набір команд:

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

приклад

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

Де ми працюємо, ми вкладаємо це в деякі з наших сценаріїв технічного обслуговування, щоб ми автоматично запускали це після того, як робимо reorgs, щоб переконатися, що ми повернемо місце на диску. У нашому випадку ми використовуємо DB2 LUW 9.7 FP 4, тому не завадить повторно перевірити Інформаційний центр на 9.5, щоб переконатися, що у вас є доступ до потрібної інформації для вашої версії.

РЕДАКТУВАННЯ: Якщо ваші табличні простори надходили з бази даних, оновленої до DB2 9.7, напевно, у вас не буде встановлений відновлюваний атрибут зберігання. Це справедливо, навіть якщо ви переходите з DMS до автоматичного зберігання. У будь-якому випадку укуси, так як фактично не можете знизити високий рівень води. Ви повинні скинути таблицю та дані, скинути таблиці. Потім заново створіть область таблиць за допомогою автоматичного зберігання та імпортуйте дані для своїх таблиць.

У таблиці MY_TBLмістяться великі двійкові дані в BLOBстовпці. Документація REORGкоманди говорить, що DB2 уникає реорганізації таких об'єктів, оскільки це забирає багато часу і не покращує кластеризацію. Однак DB2 можна змусити реорганізувати дані LOB, якщо LONGLOBDATAвказана опція. Невикористаний простір може бути повторно використаний DB2, тому вставлення нових даних спочатку заповнить наявні, невикористані сторінки перед тим, як виділити нові.

Біг

REORG TABLE MY_TBL LONGLOBDATA

успішно відновлено 2,5 Гб дискового простору, який використовувала порожня таблиця.

Я не знав про цей варіант і курирував його вперше, коли прочитав документацію.