Pourquoi DELETE + REORG ne libère-t-il pas l'espace disque (DB2)?

Dans DB2, j'ai une table contenant de grandes données binaires. Maintenant, j'ai purgé toute la table et exécuté runstats, reorg, runstats, mais la quantité d'espace disque occupée ne change pas. Qu'est-ce qui pourrait mal ici?

La table réside dans son propre espace de table que j'ai créé comme suit:

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;

J'ai supprimé / réorganisé comme suit:

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 table MY_TBL a pris 2,5 Go avant tout cela et après suppression / réorientation, elle n'utilise que 3 Mo de moins.

FWIW: J'exécute DB2 / NT v9.5.2.

Je vais supposer que vous utilisez le stockage automatique. (Non pas que cela puisse se produire autrement ... il est juste facile que cela se produise avec le stockage automatique.)

Le problème est probablement que votre base de données a récupéré l'espace pour elle-même mais n'a pas libéré le disque sur le système d'exploitation. Cela peut être montré très facilement en vérifiant le High Water Mark pour le tablespace.

Faites ce qui suit

db2 list tablespaces show detail

Cela vous montrera chaque espace disque logique et ce qu'il utilise sur le disque. Used pagesest le nombre de pages de disque utilisées par la base de données. En comparant cela contre total pages(le total réclamé sur le disque) et le High water mark (pages)vous montrera si vous "réclamez" plus que ce dont vous avez réellement besoin. (c.-à-d. pages peu utilisées, nombre total de pages très élevé et marque High Water Mark près du nombre total de pages).

Pour se débarrasser de cet espace inutilisé et revenir au système d'exploitation que vous exécutez la commande suivante (sous stockage automatique): db2 alter tablespace <tablespace name> reduce max. exemple

db2 alter tablespace ts1 reduce max;

Cela entraînera DB2 à baisser la ligne des hautes eaux et à libérer le disque inutilisé vers le système d'exploitation. (Notez que vous ne pouvez le faire que pour les espaces de table standard et volumineux, pas pour les espaces de table temporaires du système ou temporaires de l'utilisateur).

Si vous utilisez DMS sans stockage automatique, vous devez utiliser un ensemble de commandes légèrement différent:

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

exemple

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

Là où nous travaillons, nous l'intégrons dans certains de nos scripts de maintenance afin de l'exécuter automatiquement après avoir effectué des réorganisations pour nous assurer de récupérer de l'espace disque. Dans notre cas, nous utilisons DB2 LUW 9.7 FP 4, donc cela ne fait pas de mal de vérifier le centre de documentation pour 9.5 pour vous assurer que vous avez accès aux bonnes informations pour votre version.

EDIT: Si vos espaces de table provenaient d'une base de données mise à niveau vers DB2 9.7, vous n'aurez probablement pas l'attribut de stockage récupérable défini. Cela est vrai même si vous passez du DMS au stockage automatique. Dans les deux cas, vous mordez car vous ne pouvez pas réellement abaisser la ligne des hautes eaux. Vous devez vider la table et les données, supprimer les espaces de table. Recréez ensuite l'espace disque logique à l'aide du stockage automatique et importez les données de vos tables.

Le tableau MY_TBLcontient de grandes données binaires dans une BLOBcolonne. La documentation de la REORGcommande indique que DB2 évite de réorganiser ces objets car cela prend du temps et n'améliore pas le clustering. Cependant, DB2 peut être forcé de réorganiser les données LOB si l' LONGLOBDATAoption est spécifiée. L'espace inutilisé peut être réutilisé par DB2, donc l'insertion de nouvelles données remplira d'abord les pages existantes et inutilisées avant d'allouer de nouvelles.

Fonctionnement

REORG TABLE MY_TBL LONGLOBDATA

a récupéré avec succès les 2,5 Go d'espace disque utilisés par la table vide.

Je ne connaissais pas cette option et l'ai supervisée la première fois que j'ai lu la documentation.