Vous n'êtes pas identifié(e).
Pages : 1
Je réalise les opérations de VACUUM à un moment où il y a pas de sollicitations sur le serveur.
On réalise d'ors et déjà des VACUUM standards chaque jour sur les tables les plus sollicités.
Néanmoins, comme dit au début, certaines ont une très grande volatilité.
cause de transactions très longues.
Qu'entendez vous par transactions très longues ?
Merci pour les réponses.
Pour vous, il n'est pas nécessaire de réaliser un VACUUM full sur la base mais cela suffit sur les tables ?
Je vais regarder les paramétrages de l'autovacuum.
Lorsqu'on ne réalise pas de VACUUM full pendant plus de 3 semaines, nos bases saturent.
Qu'entendez-vous par saturer ?
On arrive à saturer l'espace mémoire des disques.
Bonjour,
Je me permets de relancer mon sujet.
Dans quel cas l'utilisation d'un VACUUM full est pertinent ?
Lorsqu'on ne réalise pas de VACUUM full pendant plus de 3 semaines, nos bases saturent. Ainsi, je pense que cette opération se justifie afin de libérer de l'espace mémoire. Néanmoins, est il possible de réaliser un VACUUM full uniquement sur les tables les plus sollicités ? En effet, en cas de fusion de nos bases, le temps de réalisation d'un VACUUM deviendra sans doute particulièrement trop long.
Merci de votre aide
Nous avons choisi de réaliser des VACUUM full sur la base complète après de nombreuses saturations de notre serveur.
En effet, la taille de plusieurs de nos tables présentent une important volatilité (facteur x10). Ces tables comportant plusieurs centaines de millions d'entrées, nous avons préférés réalisé des VACUUM full plutot que des VACUUM simple.
Bonjour
Je dispose actuellement de 9 bases de données que je souhaiterais fusionner par série de 3. Or cela signifie que je vais passer de 60 tables à environ une centaine avec une augmentation particulièrement conséquente de la taille de ma base complète (100Go à + de 200Go)
Nous réalisons actuellement des VACUUM full hebdomadaire sur chacune des bases + un vacuum full journalier sur les tables les plus sollicitées.
Si nous procédons à cette fusion de nos bases, je crains que l'opération de VACUUM full sur une base deviennent quasiment irréalisable dans un délai acceptable. Ainsi, je voudrais savoir si l'opération de VACUUM full réalisée sur chacune de mes tables équivaut à réaliser un vacuum full sur l'ensemble de ma base.
Merci !
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
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
Voici le résultat 146 282 340 352
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
Dans PgAdmin, en selectionnant une table :
Onglet Statistique
Taille de la table TOAST : aucun
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.
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 ?
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
Bonjour,
Désolé pour la réponse tardive.
Le problème provenait coté serveur qui refusait l'accès à l'utilisateur Postgresql aux fichiers tablspace. Une simple modification des droits a permis de corriger le problème
Bonjour,
J'ai essayé cette solution mais toujours le même problème...
Bonjour,
Suite à des anomalies au niveau de serveur contenant PostgreSql, nous l'avons reconfiguré et reconfigurer les disques virtuelles. Nous avions auparavant sauvegarder sur un disque temporaire l'ensemble des données du disques (dont les tablespaces). Après le reconfiguration et le reparamétrage des disques, nous avons restaurer les données sur le disque.
Les tablespace situées sur le disque principale (le C:) ne pose pas de problème et nous arrivons à nous connecter sans problème. Par contre, nous avons crée un second disque virtuel (le E:) qui semble avoir des connections avec Postgre.
Depuis ce changement, je ne peux plus accéder aux tables situés sur un des disques virtuels dû aux refus d’accéder aux tablespaces. En effet, le message d'erreur est toujours le même :
ERROR : FATAL: could not open file "pg_tblspc/18150/PG_9.4_201409291/19875/195082": Permission denied
(les chiffres évoluent selon ma BDD et la table recherché).
J'ai donné les droits aux utilisateurs pour accèder aux tablespaces, le firewall du serveur a été désactivé
L'erreur est permission denied.
Parfois, cela conduit à des interruptions de communication du serveur inexplicable :
ERROR : server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request
Merci de votre aide,
Cordialement,
Simon
Pages : 1