Почему DELETE + REORG не освобождает дисковое пространство (DB2)?

В DB2 у меня есть таблица, содержащая большие двоичные данные. Теперь я очистил всю таблицу и запустил runstats, reorg, runstats, но количество занятого дискового пространства не меняется. Что здесь может быть не так?

Таблица находится в своем собственном табличном пространстве, которое я создал следующим образом:

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

Там, где мы работаем, мы помещаем это в некоторые из наших сценариев обслуживания, чтобы мы автоматически запускали это после перезапусков, чтобы убедиться, что мы освобождаем дисковое пространство. В нашем случае мы используем DB2 LUW 9.7 FP 4, поэтому не повредит дважды проверить Информационный центр на 9.5, чтобы убедиться, что у вас есть доступ к нужной информации для вашей версии.

РЕДАКТИРОВАТЬ: Если ваши табличные пространства взяты из базы данных, обновленной до DB2 9.7, у вас, вероятно, не будет установлен атрибут восстанавливаемого хранилища. Это верно, даже если вы переходите с DMS на автоматическое хранение. В любом случае кусается, так как вы не можете на самом деле снизить отметку максимальной воды. Вы должны сбросить таблицу и данные, отбросить табличные пространства. Затем заново создайте табличное пространство с помощью автоматического хранения и импортируйте данные для ваших таблиц.

Таблица MY_TBLсодержит большие двоичные данные в BLOBстолбце. В документации REORGкоманды говорится, что DB2 избегает реорганизации таких объектов, потому что это отнимает много времени и не улучшает кластеризацию. Однако DB2 можно принудительно реорганизовать данные больших объектов, если LONGLOBDATAуказан этот параметр. DB2 может повторно использовать неиспользуемое пространство, поэтому вставка новых данных сначала заполнит существующие, неиспользуемые страницы, прежде чем выделять новые.

Бег

REORG TABLE MY_TBL LONGLOBDATA

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

Я не знал об этой опции и следил за ней, когда впервые прочитал документацию.