¿Por qué DELETE + REORG no libera espacio en disco (DB2)?

En DB2 tengo una tabla que contiene datos binarios grandes. Ahora purgué toda la tabla y ejecuté runstats, reorg, runstats, pero la cantidad de espacio en disco no cambia. ¿Qué podría estar mal aquí?

La tabla reside en su propio espacio de tabla que creé de la siguiente manera:

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;

Eliminé / reordené de la siguiente manera:

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

La tabla MY_TBL ocupaba 2.5GB antes de todo eso y después de eliminar / reorganizar usa solo 3 MB menos.

FWIW: estoy ejecutando DB2 / NT v9.5.2.

Voy a adivinar que estás usando almacenamiento automático. (No es que esto pueda suceder de otra manera ... es fácil que esto suceda con el almacenamiento automático).

El problema es más probable que su base de datos haya recuperado el espacio para sí misma pero no haya devuelto el disco al sistema operativo. Esto se puede mostrar muy fácilmente al marcar la Marca de nivel superior para el espacio de tabla.

Haz lo siguiente

db2 list tablespaces show detail

Esto le mostrará cada espacio de tabla y lo que está utilizando en el disco. Used pageses cuántas páginas de disco está usando la base de datos. Comparando eso con total pages(el total reclamado en el disco) y el High water mark (pages)le mostrará si está "reclamando" más de lo que realmente necesita. (es decir, páginas con poco uso, páginas con un total muy alto y una marca de nivel alto cerca de las páginas totales).

Para deshacerse de este espacio no utilizado y devolverlo al sistema operativo que le emita el siguiente (en condiciones de almacenamiento automático): db2 alter tablespace <tablespace name> reduce max. ejemplo

db2 alter tablespace ts1 reduce max;

Eso hará que DB2 baje la marca de límite superior y libere el disco no utilizado al sistema operativo. (Tenga en cuenta que solo puede hacer esto para espacios de tabla regulares y grandes, no para espacios de tabla temporales del sistema o temporales del usuario).

Si está utilizando DMS sin almacenamiento automático, debe utilizar un conjunto de comandos ligeramente 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);

ejemplo

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

Donde trabajamos, lo ponemos en algunos de nuestros scripts de mantenimiento para que lo ejecutemos automáticamente después de realizar las reorganizaciones para asegurarnos de recuperar el espacio en disco. En nuestro caso, utilizamos DB2 LUW 9.7 FP 4, por lo que no está de más verificar el Centro de información de 9.5 para asegurarse de que tiene acceso a la información correcta para su versión.

EDITAR: si sus espacios de tabla provienen de una base de datos actualizada a DB2 9.7, probablemente no tendrá establecido el atributo de almacenamiento recuperable. Esto es cierto incluso si actualiza de DMS a almacenamiento automático. De cualquier manera, muerde, ya que en realidad no puede bajar la marca de agua alta. Debe volcar la tabla y los datos, descartar los espacios de tabla. Luego, vuelva a crear el espacio de tabla utilizando el almacenamiento automático e importe los datos para sus tablas.

La tabla MY_TBLcontiene datos binarios grandes en una BLOBcolumna. La documentación del REORGcomando dice que DB2 evita reorganizar dichos objetos porque lleva mucho tiempo y no mejora la agrupación. Sin embargo, se puede obligar a DB2 a reorganizar los datos LOB si LONGLOBDATAse especifica la opción. El espacio no utilizado puede ser reutilizado por DB2, por lo que la inserción de nuevos datos llenará primero las páginas existentes no utilizadas antes de asignar nuevas.

Corriendo

REORG TABLE MY_TBL LONGLOBDATA

recuperó con éxito los 2.5GB de espacio en disco que estaba usando la tabla vacía.

No conocía esta opción y la supervisé la primera vez que leí la documentación.