Re: [pgsql-fr-generale] BD impossible à recharger

Bonsoir,

Le 5 avr. 2012 à 22:15, Alain a écrit :

> On Thu, 05 Apr 2012 21:20:57 +0200
> Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:
>
>> On Thu, 2012-04-05 at 21:19 +0200, Guillaume Lelarge wrote:
>>> On Thu, 2012-04-05 at 21:03 +0200, Alain wrote:
>>>> On Thu, 5 Apr 2012 20:02:48 +0200
>>>> Alain <eurlix(dot)alain(at)free(dot)fr> wrote:
>>>>
>>>>> On Thu, 05 Apr 2012 18:38:51 +0200
>>>>> Sébastien Lardière <slardiere(at)hi-media(dot)com> wrote:
>>>>>
>>>>>> On 04/05/2012 06:25 PM, Alain wrote:
>>>>>>>
>>>>>>> Autant que je me rappelle, le premier message d'erreur concernait un
>>>>>>> utilisateur occasionnel (jeanne) qui n'était pas créé sur ce PC. J'au
>>>>>>> créé l'utilisateur et relancé.
>>>>>>
>>>>>> En effet, les objets globaux ne sont pas créés par pg_restore.
>>>>>>
>>>>>> Pour ce type d'objets, vous pouvez utiliser pg_dumpall -g, afin de
>>>>>> récupérer la liste des users et groups
>>>>>>
>>>>>>> J'avais avant créée la BD "gesdil", ce qui n'était sans doute pas
>>>>>>> indispensable.
>>>>>>> J'avais peut-être lancé initialement la restauration sans le "-c" et
>>>>>>> certainement sans la redirection. J'ai ensuite ajouté le "-c" car la
>>>>>>> majeure partie des tables sont créées (98/102).
>>>>>>> Ça fait deux jours (et une partie des nuits) que je bataille sur ce
>>>>>>> problème et mes souvenirs peuvent être un peu confus.
>>>>>>> Je pourrais maintenant faire un "dropdb" qui me remettrait dans la
>>>>>>> situation initiale et recommencer à zéro ?
>>>>>>>
>>>>>>
>>>>>> Je vous conseille en effet cette option (dropdb puis createdb à
>>>>>> nouveau), vous êtes certains d'obtenir une DB vierge, et vous minimisez
>>>>>> le risque d'erreurs.
>>>>>>
>>>>>> --
>>>>>> Sébastien Lardière
>>>>>> Hi-Media Nantes
>>>>>> DBA PostgreSQL
>>>>>> 0228082071 / 0626595833
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
>>>>>> To make changes to your subscription:
>>>>>> http://www.postgresql.org/mailpref/pgsql-fr-generale
>>>>>>
>>>>> Vous n'avez sans doute pas reçu mon message précédent envoyé sous un
>>>>> mauvais nom (pas abonné) :
>>>>> Pas de message d'erreur lors du pg_dump, précédé par un vacuum.
>>>>>
>>>>> J'ai lancé : pg_restore --list gesdil_sv04
>>>>> sans problème.
>>>>>
>>>>> Pas de problème signalé non plus sur "pg_restore -l"
>>>>> Par contre, pg_restore -s ne crée que 100 tables sur 102,
>>>>> sans les commentaires ce qui rend difficile le diff,
>>>>> Des 2 tables manquantes, l'une est temporaire et vide, mais l'autre, la
>>>>> table des articles est la principale (855 563 éléments) et c'est la
>>>>> principale.
>>>>>
>>>>> Les autres tables créées sont vides, évidemment ...
>>>>>
>>>>>
>>>>> J'ai depuis fait dropdb puis createdb et pg_restore, la base se charge,
>>>>> mais avec "-v", il risquait d'y en avoir pour un certain temps ...
>>>>> J'ai cancellé puis relancé (en redirigeant la sortie dans un fichier)
>>>>>
>>>>> J'aurai le résultat dans une ou deux heures, ou demain, ...
>>>>> S'il manque une ou des tables, je pense arriver à les récupérer.
>>>>>
>>>>> Merci pour votre aide, ainsi qu'à Guillaume Lelarge
>>>>> --
>>>>> Alain <eurlix(dot)alain(at)free(dot)fr>
>>>>>
>>>>> --
>>>>> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
>>>>> To make changes to your subscription:
>>>>> http://www.postgresql.org/mailpref/pgsql-fr-generale
>>>>>
>>>> Bonsoir,
>>>>
>>>> J'ai crié victoire un peu trop tôt :
>>>> pg_restore a planté silencieusement et la BD gesdil est vide.
>>>> (Même les tables crées par "pg_restore -s " ont disparu.
>>>>
>>>> J'en reviens à l'idée de restaurer les tables une par une (il n'y en a
>>>> qu'une centaine et je dois pouvoir faire un script pour ça).
>>>>
>>>> Avez-vous une autre idée ?
>>>>
>>>
>>> Comme déjà dit, sans plus de rigueur, on n'y arrivera pas. Votre
>>> pg_restore plante sur quoi ? le lancez-vous sur une base vide ? avec
>>> quelles options ?
>>>
>>
>> Autre chose, si pg_restore ne dit rien, c'est qu'il a réussi ce que vous
>> lui avez demandé de faire. C'est pourquoi les options que vous lui avez
>> donné sont si importantes.
>>
>>
>> --
>> Guillaume
>> http://blog.guillaume.lelarge.info
>> http://www.dalibo.com
>>
>>
> Comme indiqué par Sébastien Lardière, j'ai à chaque fois fait
> "dropdb gesdil" puis "createdb gesdil"
> Je l'ai lance comme ça :
> $ pg_restore gesdil_sv04 >restore.como 2>&1 &
> [1] 18438
> et j'ai obtenu ceci :
> -rw-rw-r-- 1 auberon auberon 228982784 avr 5 21:00 restore.como
> Mais au final la BD gesdil était vide !
> (Même plus les tables crées par pg_restore -s )
> Ça parait aberrant, car il n'y avait pas de -v, mais j'ai considéré
> qu'il avait conservé qqchose du lancement précédent, avec -v, que
> j'avais breaké !

Il n'y a aucune aberration dans ce qu'il se produit. Regardez votre fichier restore.como, il s'agit d'un script SQL que pg_restore a généré à partir de votre fichier dump gesdil_sv04. En fait, vous n'indiquez pas à pg_restore de restaurer dans une base de données particulière. L'option -d nombase permet de le lui indiquer.
Essayez plutôt avec la commande pg_restore -d gesdil gesdil_sv04.

Cordialement,
Thomas