Vous n'êtes pas identifié(e).
Bonjour,
Le titre est un peu long mais résume particulièrement bien le problème que je rencontre.
Lorsque je fait la somme de mes tables, j'obtiens un résultat autour de 100 Go. Pourtant, lorsque je regarde la taille de ma base de données, celle-ci fait plus de 250 Go.
Ainsi, il y a 150 Go que je n'arrive pas à récupérer. J'ai déjà réalisé pour l'ensemble de ma base de données depuis l'interface de PgAdmin III:
VACUUM
VACUUM FULL
ANALYZE
REINDEX
Malgré ces opérations, impossible de réduire la taille de ma base. Auriez une solution pour libérer cet espace mémoire ?
Merci par avance
Hors ligne
Comment calculez-vous la taille de vos tables ? Est-ce que vous incluez les index, vues matérialisées...
Julien.
https://rjuju.github.io/
Hors ligne
Pour calculer, j'utilise l'outil statistique fournit directement par PgAdmin.
Par ailleurs, j'ai executer la requête ci dessous pour connaitre le détail de chacune de mes tables
SELECT schemaname, tablename, tablespace, pg_size_pretty(taille) AS taille_table, pg_size_pretty(taille_totale) AS taille_totale_table
FROM (SELECT *,
pg_relation_size(schemaname || '.' || tablename) AS taille,
pg_total_relation_size(schemaname || '.' || tablename) AS taille_totale
FROM pg_tables) AS tables
ORDER BY taille_totale DESC;
Pour connaitre la taille de ma base complète, j'ai regardé l'onglet statistique dans PgAdmin, vérifier la taille prise par les tablespaces sur le disque (toutes mes tables sont sur une seule tablespace) et la requete
select pg_database_size('mabase');
Tout cela continue a entretenir la différence entre somme des tables et taille complète de ma base. Par ailleurs, le VACUUM full n'aurait pas du libérer l'espace mémoire ?
Hors ligne
pg_relation_size ne vous donne pas la taille de la table, mais la taille de la partie HEAP de la table. Il vous manque donc la partie TOAST. Aucune idée de votre version de PostgreSQL mais si vous avez une version suffisamment récente, utilisez plutôt pg_table_size.
Autre poblème, vous ne prenez pas en compte la taille des autres objets : index et vues matérialisées.
Quant au VACUUM FULL, il libère de l'espace disque et non pas de l'espace mémoire. De plus, il ne libère de l'espace disque que s'il peut le faire (ie, qu'il y a des espaces morts dans vos tables).
Guillaume.
Hors ligne
Bonjoru,
Merci de votre réponse. Tout d'abord, je n'ai pas d'élément TOASTE.
J'ai refait mes calculs en tenant compte des index et vues. Pourtant je continue à trouver un résultat différent entre somme des tables et taille de ma base. De plus, cette base à pour but de servir de test et contient donc moins de ligne que ma base de production. Or malgré un nombre de ligne inférieure, elle prend plus d'espace sur le disque.
Auriez vous une idée de comment réduire ma la taille de ma base de données ? J'ai lu pas mal de documentation et n'ai rien réussi à trouver qui me permettrait de gagner l'espace mémoire.
Hors ligne
Tout d'abord, je n'ai pas d'élément TOASTE.
Vous avez vérifié ? Si oui, comment ?
Julien.
https://rjuju.github.io/
Hors ligne
Dans PgAdmin, en selectionnant une table :
Onglet Statistique
Taille de la table TOAST : aucun
Hors ligne
Dans PgAdmin, en selectionnant une table :
Oubliez pgAdmin et utilisez les requêtes qui permettent de connaître la taille des objets.
Que vous donne les deux requêtes suivantes :
SELECT pg_database_size(oid) FROM pg_database WHERE datname='nom de la base';
SELECT sum(pg_table_size(oid)) FROM pg_class;
Auriez vous une idée de comment réduire ma la taille de ma base de données ?
Il faudrait déjà savoir d'où vient l'incohérence avant d'aller plus loin.
Guillaume.
Hors ligne
Pour le coup, j'ai réalisé les requetes :
SELECT pg_database_size(oid) FROM pg_database WHERE datname='nom de la base'; --> 259 164 998 304
SELECT sum(pg_table_size(oid)) FROM pg_class;--> 105 487 474 688
Soit un facteur de 2,5
Hors ligne
Que donne la requête suivante ?
SELECT sum(pg_total_relation_size(oid)) FROM pg_class;
Stéphane Schildknecht
Conseil, formations et support PostgreSQL
http://www.loxodata.com
Hors ligne
Voici le résultat 146 282 340 352
Hors ligne
En faite, je n'avais pas lancé la requête sur la bonne base. Le résultat de SELECT sum(pg_total_relation_size(oid)) FROM pg_class; est 105 487 474 688
Hors ligne
Si quelqu'un a placé des fichiers dans le répertoire de la base, ils sont comptabilisés par pg_database_size, mais pas par pg_table_size.
Guillaume.
Hors ligne
En faite, je n'avais pas lancé la requête sur la bonne base. Le résultat de SELECT sum(pg_total_relation_size(oid)) FROM pg_class; est 105 487 474 688
Bizarrement, pg_total_relation_size et pg_table_size donnent le même résultat.
Ce qui signifieraient qu'il n'y a pas d'index, ni de toast.
Quel est votre OS et votre type de filesystem ?
Est-il possible que des fichiers anciens, ne correspondant plus à aucun objet de la base n'aient pas été supprimés ?
Que donne un "du -sh" sur le répertoire de la base ?
Avez-vous des fichiers surnuméraires dans ce répertoire ?
Stéphane Schildknecht
Conseil, formations et support PostgreSQL
http://www.loxodata.com
Hors ligne
Bonjour,
Réalisation à nouveau de la requete est 176 872 087 552. J'avais du supprimer les index à un moment pour voir leurs effets sur les bases.
Il semblerait que j'ai trop de fichier dans le repertoire non rattaché. Néanmoins comment, savoir lesquels puis je supprimer sans risque.
Après analyse, il semblerait qu'il y a eu une opération de VACUUM qui m'ai généré des fichiers supplémentaires qui n'ont pas été supprimé depuis car non rattaché à un seul objet.
Merci par avance
Dernière modification par Shaar (10/10/2016 15:22:45)
Hors ligne
Ça me paraît assez peu crédible. Néanmoins, pour rétablir la situation, le mieux est de sauvegarder la base et de la restaurer. Ce sera beaucoup plus sûr que de supprimer les fichiers "en trop".
Guillaume.
Hors ligne