Início / dba / Perguntas / 41577
Accepted
Alexander Tobias Bockstaller
Asked: 2013-05-07 01:44:31 +0800 CST

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

  • 772

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

A tabela reside em seu próprio tablespace que criei da seguinte forma:

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;

Eu apaguei/reorganizei da seguinte forma:

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 ocupava 2,5 GB antes de tudo isso e depois de deletar/reordenar usa apenas 3 MB a menos.

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

db2 maintenance

2 respostas

  1. Vou adivinhar que você está usando armazenamento automático. (Não que isso pudesse acontecer de outra forma... é apenas fácil que isso aconteça com o armazenamento automático.)

    O problema mais provável é que seu banco de dados recuperou o espaço para si mesmo, mas não liberou o disco de volta para o sistema operacional. Isso pode ser mostrado facilmente verificando o High Water Mark para o tablespace.

    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 com 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, poucas páginas usadas, total de páginas muito alto e uma marca d'água alta próxima ao total de páginas).

    Para se livrar desse espaço não utilizado e devolvê-lo ao sistema operacional, você emitiria o seguinte (em armazenamento automático): db2 alter tablespace <tablespace name> reduce max. exemplo

    db2 alter tablespace ts1 reduce max;

    Isso fará com que o DB2 reduza a marca d'água alta e libere o disco não utilizado de volta ao 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 DMS sem armazenamento automático, precisará usar um conjunto de comandos ligeiramente 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 depois de fazermos reorganizações para garantir a recuperação do espaço em disco. Em nosso caso, usamos o DB2 LUW 9.7 FP 4, portanto, não custa nada verificar novamente o Centro de Informações para 9.5 para garantir que você tenha acesso às informações corretas para sua versão.

    EDIT: Se seus tablespaces vierem 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, você não pode realmente diminuir a marca d'água alta. Você tem que despejar a tabela e os dados, descartar os tablespaces. Em seguida, recrie o tablespace usando armazenamento automático e importe os dados para suas tabelas.

    • 22
  2. Best Answer

    A tabela MY_TBLcontém grandes dados binários em uma BLOBcoluna. A documentação do REORGcomando diz que o DB2 evita reorganizar tais objetos porque é demorado e não melhora o clustering. 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 existentes e não utilizadas antes de alocar novos.

    Corrida

    REORG TABLE MY_TBL LONGLOBDATA

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

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

    • 9

relate perguntas