Por que o DELETE + REORG não libera espaço em disco (DB2)?

No DB2, tenho uma tabela contendo grandes dados binários. Agora limpei a tabela inteira e executei runstats, reorg, runstats, mas a quantidade de espaço em disco ocupada não muda. Oque pode estar errado aqui?

A tabela reside em seu próprio espaço de tabela que eu criei da seguinte maneira:

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;

Excluí / reorguei da seguinte maneira:

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

A tabela MY_TBL ocupou 2,5 GB antes de tudo isso e depois de excluir / reorganizar, usa apenas 3 MB a menos.

FWIW: Estou executando o DB2 / NT v9.5.2.

Suponho que você esteja usando armazenamento automático. (Não que isso possa acontecer de outra forma ... é fácil fazer isso acontecer com o armazenamento automático.)

O problema é mais provável que seu banco de dados tenha recuperado o espaço por si mesmo, mas não liberou o disco de volta para o sistema operacional. Isso pode ser mostrado com muita facilidade, verificando a marca d'água alta no espaço de tabela.

Faça o seguinte

db2 list tablespaces show detail

Isso mostrará cada espaço de tabela e o que ele está usando no disco. Used pagesé quantas páginas de disco o banco de dados está usando. Comparando isso contra total pages(o total reivindicado no disco) e o High water mark (pages)mostrará se você está "reivindicando" mais do que realmente precisa. (ou seja, páginas com pouco uso, total de páginas muito altas e uma marca d'água alta próxima ao total de páginas).

Para se livrar deste espaço não utilizado e devolvê-lo para o sistema operacional que você iria emitir o seguinte (sob o armazenamento automático): db2 alter tablespace <tablespace name> reduce max. exemplo

db2 alter tablespace ts1 reduce max;

Isso fará com que o DB2 abaixe a marca d'água máxima e libere o disco não utilizado de volta para o sistema operacional. (Observe que você só pode fazer isso para espaços de tabela regulares e grandes, não para espaços de tabela temporários do sistema ou temporários do usuário).

Se você estiver usando o DMS sem armazenamento automático, precisará usar um conjunto de comandos um pouco diferente:

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

exemplo

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

Onde trabalhamos, colocamos isso em alguns de nossos scripts de manutenção para que possamos executá-lo automaticamente após reorganizarmos para garantir a recuperação do espaço em disco. No nosso caso, usamos o DB2 LUW 9.7 FP 4, portanto, não é necessário checar novamente o Information Center for 9.5 para garantir que você tenha acesso às informações corretas para sua versão.

EDIT: Se seus espaços de tabela vieram de um banco de dados atualizado para o DB2 9.7, você provavelmente não terá o atributo de armazenamento recuperável definido. Isso é verdade mesmo se você atualizar do DMS para o armazenamento automático. De qualquer maneira morde como você não pode realmente diminuir a marca d'água alta. Você precisa despejar a tabela e os dados, soltar os espaços de tabela. Em seguida, recrie o espaço de tabela usando armazenamento automático e importe os dados para suas tabelas.

A tabela MY_TBLcontém grandes dados binários em uma BLOBcoluna. A documentação do REORGcomando diz que o DB2 evita a reorganização de tais objetos porque consome tempo e não melhora o armazenamento em cluster. No entanto, o DB2 pode ser forçado a reorganizar os dados LOB se a LONGLOBDATAopção for especificada. O espaço não utilizado pode ser reutilizado pelo DB2, portanto, a inserção de novos dados primeiro preencherá as páginas não usadas existentes antes de alocar novos.

Corrida

REORG TABLE MY_TBL LONGLOBDATA

recuperou com êxito os 2,5 GB de espaço em disco que a tabela vazia estava usando.

Eu não conhecia essa opção e a supervisionei na primeira vez que li a documentação.