Vous n'êtes pas identifié(e).
Dernière question ... comment savoir si les données sont en train d'être chargées ? En bref : suivre la restauration des données.
Le "psql -l" m'a effectivement permis de constater que ma base a bien été créée. Merci Marc ! 
Hors ligne
La vue pg_stat_activity vous donnera la liste des requêtes en cours d'exécution. Vous devriez voir les COPY, puis les create index etc
Julien.
https://rjuju.github.io/
Hors ligne
Le problème est que j'ai eu à créer tous les users et les répertoires pour les tablespaces ... sinon le restore fonctionnait pas ... "forcément" vous allez dire, mais fallait-il encore savoir que pg_restore n'allait pas le faire. Encore que pour les tablespaces j'aurais pu m'en douter !
Pour restaurer les utilisateurs, il faut passer par pg_dumpall -g et psql pour les restaurer.
pg_restore: [programme d'archivage (db)] Erreur pendant le traitement de la TOC (« PROCESSING TOC ») :
pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 32 ; 1255 17753 FUNCTION pg_stat_statements() postgres
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: n'a pas pu accéder au fichier « $libdir/pg_stat_statements » : Aucun fichier ou répertoire de ce type
Command was: CREATE FUNCTION pg_stat_statements(OUT userid oid, OUT dbid oid, OUT query text, OUT calls bigint, OUT total_time double pre...
[...]
Le serveur n'a pas les contrib d'installées.
Julien.
https://rjuju.github.io/
Hors ligne
Le contrib pg_stat_statement est installé sur le serveur de départ, mais pas sur celui d'arrivée (il doitmanquer le packages de contribs postgres sur le serveur d'arrivée). Si vous voulez l'activer sur le serveur d'arrivée il faudra aussi le mettre dans shared_preload_libraries, dans le fichiers postgresql.conf, comme sur le serveur de départ.
Marc.
Hors ligne
Je reviens rapidement sur pg_restore. Ce n'est pas qu'il ne les restaure pas, c'est que pg_dump ne sauvegard epas les définitions des tablespaces et des utilisateurs. Seul pg_dumpall le fait. Et c'est très clairement indiqué dans la documentation
Guillaume.
Hors ligne
Le contrib pg_stat_statement est installé sur le serveur de départ, mais pas sur celui d'arrivée (il doitmanquer le packages de contribs postgres sur le serveur d'arrivée). Si vous voulez l'activer sur le serveur d'arrivée il faudra aussi le mettre dans shared_preload_libraries, dans le fichiers postgresql.conf, comme sur le serveur de départ.
Bonjour,
Est-ce que cela empêche la restauration des données ?
Je ne peux malheureusement pas me connecter pour l'instant pour m'en assurer avec pg_stat_activity.
Merci messieurs pour votre aide ! 
Et c'est bien noté pour le pg_dumpall !
Gôm
Dernière modification par gom (20/01/2013 22:31:28)
Hors ligne
Est-ce que cela empêche la restauration des données ?
Pas ce module contrib, là, non.
Guillaume.
Hors ligne
Bonjour,
Merci.
J'ai encore un problème ... j'ai à priori saturé l'espace disque :
pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 4148 ; 0 0 ACL table_1 user_dwh
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: n'a pas pu étendre la relation base/19635/1259 : Aucun espace disponible sur le périphérique
ASTUCE : Vérifiez l'espace disque disponible.
Command was: REVOKE ALL ON TABLE table_1 FROM PUBLIC;
REVOKE ALL ON TABLE table_1 FROM user_dwh;
GRANT ALL...
pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 4149 ; 0 0 ACL table_2 user_dwh
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: n'a pas pu étendre la relation base/19635/1259 : Aucun espace disponible sur le périphérique
ASTUCE : Vérifiez l'espace disque disponible.
Command was: REVOKE ALL ON TABLE table_2 FROM PUBLIC;
REVOKE ALL ON TABLE table_2 FROM user_dwh...
pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 4150 ; 0 0 ACL pg_stat_statements postgres
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: la relation « pg_stat_statements » n'existe pas
Command was: REVOKE ALL ON TABLE pg_stat_statements FROM PUBLIC;
REVOKE ALL ON TABLE pg_stat_statements FROM postgres;
GRANT ALL ON TABLE...
ATTENTION : erreurs ignorées lors de la restauration : 800
Ces commandes me disent que "non" je n'ai pas saturé le disque ! Je ne comprends pas (oui encore !). 
[root@monserveur backups_prod]# fdisk -l
Disque /dev/sda: 730.8 Go, 730815528960 octets
255 heads, 63 sectors/track, 88849 cylinders
Unités = cylindres de 16065 * 512 = 8225280 octetsPériphérique Amorce Début Fin Blocs Id Systême
/dev/sda1 * 1 261 2096451 83 Linux
/dev/sda2 262 88849 711583110 8e Linux LVM
[root@monserveur backups_prod]# mount
/dev/sda1 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/mapper/vg_root-lv_sigexpl on /sigexpl type ext3 (rw,noatime)
/dev/mapper/vg_root-lv_tmp on /tmp type ext3 (rw,noatime)
/dev/mapper/vg_root-lv_app on /app type ext3 (rw,noatime)
/dev/mapper/vg_root-lv_home on /home type ext3 (rw,noatime)
/dev/mapper/vg_root-lv_usr on /usr type ext3 (rw,noatime)
/dev/mapper/vg_root-lv_var on /var type ext3 (rw,noatime)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
/dev/mapper/vg_root-lv_pgdata on /app/pgdata type ext3 (rw,noatime)
[root@monserveur backups_prod]# du / -s -h
542G /
[root@monserveur backups_prod]# du /app -s -h
540G /app
[root@monserveur backups_prod]# du /app/pgdata -s -h
537G /app/pgdata
[root@monserveur backups_prod]# du /app/pgdata/backups_prod/ -s -h
410G /app/pgdata/backups_prod/
[root@monserveur backups_prod]# du /app/pgdata/base -s -h
127G /app/pgdata/base
[root@monserveur backups_prod]# df
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/sda1 2030736 276512 1649404 15% /
/dev/mapper/vg_root-lv_sigexpl
507748 18768 462766 4% /sigexpl
/dev/mapper/vg_root-lv_tmp
1015704 34108 929168 4% /tmp
/dev/mapper/vg_root-lv_app
10157368 3673332 5959748 39% /app
/dev/mapper/vg_root-lv_home
2031440 68720 1857864 4% /home
/dev/mapper/vg_root-lv_usr
5078656 1281392 3535120 27% /usr
/dev/mapper/vg_root-lv_var
5078656 301344 4515168 7% /var
tmpfs 12337992 0 12337992 0% /dev/shm
/dev/mapper/vg_root-lv_pgdata
667880040 562492588 71469132 89% /app/pgdata
Gôm
Dernière modification par gom (21/01/2013 10:58:24)
Hors ligne
Ça peut être un problème de quota pour cet utilisateur. Ou alors il a rencontré ce problème d'espace disque puis du ménage a été fait (par lui ou par quelqu'un d'autre).
Guillaume.
Hors ligne
Comment ça du ménage "par lui" ?
Sinon je constate que Linux me dit que j'occupe 89% d'espace disque pour cette partition, alors que 637-537 = 100 Go de dispo signifie plutôt qu'il me reste plus de 15% de libre, donc que j'occuperais 84% et quelques, et non 89% ?!
[root@monserveur backups_prod]# df -h
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/sda1 2,0G 271M 1,6G 15% /
/dev/mapper/vg_root-lv_sigexpl
496M 19M 452M 4% /sigexpl
/dev/mapper/vg_root-lv_tmp
992M 34M 908M 4% /tmp
/dev/mapper/vg_root-lv_app
9,7G 3,6G 5,7G 39% /app
/dev/mapper/vg_root-lv_home
2,0G 68M 1,8G 4% /home
/dev/mapper/vg_root-lv_usr
4,9G 1,3G 3,4G 27% /usr
/dev/mapper/vg_root-lv_var
4,9G 295M 4,4G 7% /var
tmpfs 12G 0 12G 0% /dev/shm
/dev/mapper/vg_root-lv_pgdata
637G 537G 69G 89% /app/pgdata
Dernière modification par gom (21/01/2013 13:02:00)
Hors ligne
Comment ça du ménage "par lui" ?
Et bien, il a pu supprimer des journaux de transactions ou des fichiers temporaires.
Sinon je constate que Linux me dit que j'occupe 89% d'espace disque pour cette partition, alors que 69 Go de dispo signifie plutôt qu'il me reste plus de 15% de libre, donc que j'occuperais 84% et quelques, et non 89% ?! hmm
Alors, 69*100/637 = 10.83202... ça fait donc bien du 89,quelque-chose %. Enfin, je crois
Guillaume.
Hors ligne
Je me suis mal exprimé : 637 - 537 = 100 Go de dispo théoriquement, alors que seuls 69 Go sont affichés. (J'ai édité mon précédent post.)
Si je veux relancer ma restauration, comment puis-je m'assurer de ne pas avoir à nouveau l'erreur ?
ERREUR: n'a pas pu étendre la relation base/19635/1259 : Aucun espace disponible sur le périphérique
Dernière modification par gom (21/01/2013 13:02:23)
Hors ligne
Je me suis mal exprimé : 637 - 537 = 100 Go de dispo théoriquement, alors que seuls 69 Go sont affichés.
Une partie du disque est utilisé pour le stockage des méta-données.
Si je veux relancer ma restauration, comment puis-je m'assurer de ne pas avoir à nouveau l'erreur ?
Vous ne pouvez pas vous en assurer, à moins de connaître la taille de la base au final.
Guillaume.
Hors ligne
Vous ne pouvez pas vous en assurer, à moins de connaître la taille de la base au final.
661 Go avec les index.
Hors ligne
Donc vous n'avez pas la place sur votre partition de 637 Go.
Guillaume.
Hors ligne
Je pensais avoir la place de faire ma restauration étant donné que les index sont à calculés après coup. J'ai faux ? 
Hors ligne
Tout dépend de ce que vous appelez « après coup ». Ils sont créés en fin de restauration.
Guillaume.
Hors ligne
Aïe je pensais pouvoir restaurer ma base sans les index et "relancer le pg_restore" uniquement pour la création d'index.
Est-ce possible sans éditer le dump en le coupant en 2 ?
Hors ligne
Suivant la version de postgresql et donc de pgrestore que tu utilises, c'est plus ou moins simple. Depuis la 9.2, tu as des «sections» du dump (pre-data, data et post-data).
Si c'est une version plus ancienne, le plus simple c'est certainement de faire pg_restore -l pour avoir le contenu de l'archive (mettre le résultat dans un fichier). Ensuite en éditant ce fichier, on peut choisir quoi restaurer (à coup de grep…): éviter tout ce qui est en INDEX ou en CONSTRAINT dans la restauration te permettra de ne pas restaurer les index. On injecte ces fichiers de commande avec pg_restore -L (majuscule)
Dernière modification par Marc Cousin (21/01/2013 19:13:21)
Marc.
Hors ligne
