Vous n'êtes pas identifié(e).
Pages : 1
Bonjour a tous,
A l'origine j'ai une erreur sur une table qui me pose un gros problème. Ensuite je trouve sur le site postgres.org une personne ayant eu le même problème et qu'il l'a résolu. Mais nouveau problème, je n'arrive pas a appliquer sa solution.....
Donc soit je dois trouver une autre solution, soit je dois réussir à appliquer la sienne.
Mon problème a l'origine est le suivant:
Une table me renvoie un message d'erreur à chaque fois que je tente une requête, et quand je tente de la dumper.
En-tête de page invalide dans le bloc xxxxxx de la relation "salesitems".
salesitems est le nom de la table et la PKey se nomme salesitems_pkey
DONC SI VOUS AVEZ UNE SOLUTION DIRECT POUR CETTE ERREUR ET QUI N'EST PAS CELLE CITÉE CI-DESSOUS, JE PREND....
J'ai ensuite trouvé quelqu'un qui rencontrant le meme probleme a utilisé la solution suivante:
- Demmarage du serveur postgres en mode single-user.
- VACUUM FULL ANALYZE ;
- REINDEX DATABASE mabase ;
Le souci c'est que je n'est pas réussi a démarrer mon serveur en mode single-user. Je suis sous ubuntu avec un serveur postgres 7.4.
voila ce que j'ai tenté:
1- arréter le serveur => /etc/init.d/postgresql7.4 stop
tout d'abord dans ma console, que ce soit en root ou en user postgres je ne peut lancer les commandes 'postgres' ou 'postmaster' directement???
je suis obligé de taper le path complet :
2- /usr/lib/postgresql/7.4/bin/postgres --single -D /var/lib/postgresql/7.4/main/base/ mag3 (ou mag3 est le nom de ma base)
et c'est la que ca bloque, car cette commande me renvoie l'erreur suivante:
Fatal: --single "requiert une valeur"????
de quelle valeur parle t'il ?????
j'ai trouvé cette syntaxe dans la doc postgres : postgres --single -D /usr/local/pgsql/data other-options my_database
est ce le bon moyen de démarrer le serveur en single User et si oui pourquoi ca ne fonctionne pas dans mon cas??????
Merci d'avance a tous...
Hors ligne
- Le VACUUM FULL ne résoudra pas le problème: vous avez un entête de bloc corrompu
- L'option --single n'existe que depuis la version 8.2. Avant (7.4 par exemple), l'exécutable postgres lançait directement un mode mono-utilisateur. Essayez déjà sans --single.
- Avant toute chose, faites un backup binaire de votre base
- Essayez ensuite de démarrer avec 'zero_damaged_pages' à on. Il détruira les pages corrompues. Mais évidemment, vous allez perdre des données.
- Faites un dump (pg_dump).
- Puis recréez un cluster propre et réimportez dedans. Essayez d'évaluer l'étendue des dégats 
Marc.
Hors ligne
De plus, il est possible que ce problème soit dû à un matériel défectueux. Donc n'oubliez pas de tester le matériel, voire de comprendre comment ce problème est survenu. Sinon rien ne dit que ça ne recommencera pas.
Guillaume.
Hors ligne
OK, je viens effectivement de faire les testes suivant:
Arrêt du serveur, redémarrage avec la commande postgres sans single, j'ai quand même testé le vacuum => il me renvoie toujours la même erreur...
j'ai aussi tenté le reindex database... mais sans succes...
donc il me reste votre suggestion : démarrer avec 'zero_damaged_pages' à on.
Et la je dis ok mais comment on fait? est ce une option de la commande postgres a rajouter après -D "path to DB" et avant le nom de la base ???
Merci encore
Hors ligne
Vous pouvez tout simplement le mettre dans le fichier de configuration.
Pas la peine de démarrer en mode single, le mode 'normal' marchera aussi avec le zero_damaged_pages.
Marc.
Hors ligne
Ok j'ai lu la doc et j'ai donc tenté de mettre l'option zero_damaged_pages = true dans le fichier postgresql.conf
ensuite stop et start du serveur par le fichier init.d/postgresql7.4
puis pg_dump de la base.
La j'ai encore le meme message :
En-tête de page invalide dans le bloc xxxxxx de la relation "salesitems";
mais suivi du message suivant:
page remplie de zero
est ce que cela veut dire que le dump qui est sorti est OK hormis les enregistrement corrompus????
Hors ligne
je pense… vous pouvez toujours faire un second dump et vérifier que vous n'avez plus d'erreur. Je pense que ce qui a changé entre la tentative précédente et celle-ci, c'est que l'entête de page invalide est devenu un warning au lieu d'une erreur fatale, non ?
Marc.
Hors ligne
Je ne sais pas si c'était un warning plutôt qu'une erreur fatal... je n'ai pas fait attention.
Toujours est il que effectivement, j'ai refait un pg_dump et la plus de messages....
donc je présume que je n'aurais pas un meilleur résultat et il va falloir maintenant faire l'état des lieux des données perdues....
encore merci a tous
Hors ligne
Exact. Par contre, vous pouvez estimer l'étendue des dégats, déjà, par le nombre de blocs que postgresql a du remettre à zéro.
Marc.
Hors ligne
Pages : 1
