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

18

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.

Alexander Tobias Bockstaller
la source
Est-ce que cela fonctionne pour les systèmes sur db2 v8?
Tony

Réponses:

22

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.

Chris Aldrich
la source
+1 - bon de voir un expert DB2 contribuer au site. Nous avons été faibles dans ce domaine par le passé.
Philᵀᴹ
1
Juste un petit commentaire, dans DB2 9.5, vous ne pouvez pas utiliser la syntaxe alter tablespace <tbsp> lower high watermarkor alter tablespace <tbsp> reduce max- celles-ci n'ont été introduites que dans DB2 9.7.
Ian Bjorhovde
Comme je l'ai mentionné dans mon post initial, j'ai déjà essayé la plupart de cela et cela n'a pas fonctionné. À présent, j'ai trouvé la solution moi-même: l'espace disque ne pouvait pas être récupéré car je n'avais pas spécifié l'option LONGLOBDATA, ce qui semble être nécessaire si vous souhaitez récupérer de l'espace disque à partir de BLOB ou de CLOB. Veuillez voir ma réponse à ma propre question ici. Quoi qu'il en soit, j'apprécie l'effort que vous mettez dans votre réponse, +1!
Alexander Tobias Bockstaller
9

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.

Alexander Tobias Bockstaller
la source
Bon point. Cependant, d'après ce que je viens d'apprendre sur un épisode de DB2NightShow "Attack of the Blob", vous ne voulez pas exécuter l'option LONGLOBDATA trop souvent car cela prend plus de temps et / ou cause des problèmes de performances (si vous essayez de faire des REORG en ligne) .
Chris Aldrich
Les bases de données dont nous traitons contiennent des données de journal provenant de machines industrielles. Les requêtes sur de telles bases de données ne sont pas critiques en temps, donc si les performances diminuent pendant une réorganisation, ce n'est pas un problème.
Alexander Tobias Bockstaller