Vous n'êtes pas identifié(e).

#1 19/05/2009 15:47:44

bil69
Membre

TAILLE BASE

Bonjour,

J'ai une petite question bête  : les commandes suivantes me donne 2 tailles différentes pour la base WORLD Pourquoi ???

SELECT pg_size_pretty(pg_database_size('world'));
-[ RECORD 1 ]--+--------
pg_size_pretty | 4948 kB


 du * -h

4.8M    base/1
4.8M    base/11510
4.9M    base/11511
5.5M    base/16384
20M     base

-[ RECORD 4 ]-+----------
datid         | 16384
datname       | world
numbackends   | 1
xact_commit   | 46
xact_rollback | 1
blks_read     | 212
blks_hit      | 11069
tup_returned  | 24884
tup_fetched   | 2485
tup_inserted  | 5490
tup_updated   | 36
tup_deleted   | 0


MERCI d'avance,

Dernière modification par bil69 (19/05/2009 15:48:28)

Hors ligne

#2 19/05/2009 16:12:06

Marc Cousin
Membre

Re : TAILLE BASE

Pour commencer, si on regardait non pas avec du pretty ni du -h, mais avec les tailles en octets... ?

SELECT pg_database_size('world');

du *

Parce que là les résultats ne sont même pas dans la même unité, ce qui complique les choses.


Marc.

Hors ligne

#3 19/05/2009 17:26:24

bil69
Membre

Re : TAILLE BASE

Merci beaucoup,

Voici les resultats des commandes :

test=# SELECT pg_database_size('test');
 pg_database_size
------------------
       3251392108
(1 row)

3179376 ./PGTEST01/base/16420

merci d'avance

Hors ligne

#4 19/05/2009 21:02:50

Marc Cousin
Membre

Re : TAILLE BASE

On n'est plus sur la même base, mais aucune importance : le du donne la taille en ko, le pg_database_size en octets ...

3179376*1024 = 3255681024
à comparer à      3251392108

Le reste doit être dû à des erreurs d'arrondis, d'espace perdu au niveau du système de fichiers (taille du descripteur de répertoire et de ses entrées, espace consommé dans la table d'inodes, etc ...)

Je crois qu'on peut parler de différence négligeable smile


Marc.

Hors ligne

#5 20/05/2009 09:18:01

bil69
Membre

Re : TAILLE BASE

merci pour ta réponse précise smile !!

Sinon le lancement d'un vacuum analyse donne t il la durée du vacuum a la fin ?

pg_dump -h serveur1 base | psql -h serveur2 base

Cette commande duplique les données sur le serveur 2 ???

merci d'avance

Dernière modification par bil69 (20/05/2009 09:46:50)

Hors ligne

#6 20/05/2009 10:16:41

bil69
Membre

Re : TAILLE BASE

Suite de mon pb :

Sur serveur1 :

pg_dump -h serveur1 test | pg_restore -h serveur2 test
pg_restore: [archiver] could not open input file "test": No such file or directory
pg_dump: [archiver (db)] connection to database "test" failed: could not connect to server: Connection refused
        Is the server running on host "serveur1" and accepting
        TCP/IP connections on port 5432?

J'ai pourtant créé test sur serveur2 : createdb test et postgre tourne bien sur les 2 serveurs


Merci d'avance,

Hors ligne

#7 20/05/2009 11:15:48

daamien
damien clochard

Re : TAILLE BASE

Si tu veux connaitre le temps d'execution d'un VACUUM, tu peux activer le chronomètre avec la commande :

\timing
VACUUM ANALYZE

L'option VERBOSE peut aussi t'intéresser.

Concernant la commande de duplication, tu as deux erreurs :

1/ La première est due à une mauvais utilisation de pg_restore, je te conseille vivement de plutot utiliser psql car dans ce contexte pg_restore n'apporte rien.

2/ La connexion à la base test sur le serveur1 échoue. Tu devrais t'assurer que la commande "pg_dump -h serveur1 test" fonctionne avant d'aller plus loin.

Dernier conseil, si serveur1 et serveur2 ont des versions différentes PostgreSQL ( 8.1 et 8.3 par exemple ) il est conseillé d'utiliser les binaires psql et pg_dump de la version la plus récente.

Hors ligne

#8 20/05/2009 11:47:38

bil69
Membre

Re : TAILLE BASE

Merci !!

Finalement j'ai opté pour la solution suivante :

sur serveur1 :

pg_dump -Fc test > /PGSQL/test.pg_dump

scp /PGSQL/test.pg_dump postgres@serveur2:/home/postgres


sur serveur2:

pg_restore -Fc -d test /PGSQL/test.pg_dump

Hors ligne

Pied de page des forums