Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#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
Marc.
Hors ligne
#5 20/05/2009 09:18:01
- bil69
- Membre
Re : TAILLE BASE
merci pour ta réponse précise !!
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.
damien clochard
http://dalibo.org | http://dalibo.com
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
Pages : 1