Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
Je travaille sur une base en 8.4 sous CentOs 5.4.
J'ai des messages d'erreur dans les logs :
4022 2012-11-26 15:50:50 EAT 37737 ERROR: could not open relation base/17855/1292752: Aucun fichier ou répertoire de ce type
4022 2012-11-26 15:50:50 EAT 37738 CONTEXT: writing block 0 of relation base/17855/1292752
4022 2012-11-26 15:50:50 EAT 37739 WARNING: could not write block 0 of base/17855/1292752
4022 2012-11-26 15:50:50 EAT 37740 DETAIL: Multiple failures --- write error might be permanent.
L'objet 1292752 correspond à une séquence.
Effectivement dans le répertoire il n'y a pas de fichier correspondant.
Lorsque je regarde avec PgAdmin, j'ai le même message d'erreur, de plus je vois que les valeurs sont à zéro :
INCREMENT 0
MINVALUE 0
MAXVALUE 0
START 0
CACHE 0;
Par contre le champ correspondant dans la table continue de s'alimenter correctement.
Que se passe t'il ?
Que puis-je faire ?
Hors ligne
Peux-tu mettre l'instruction que tu lance pour manipuler la sequence ?
Hors ligne
Bonjour Postgres.0,
Il s'agit d'un ordre d'insert.
La sequence correspond à un champ SERIAL dans la table.
Hors ligne
Si tu fais ça qu'est-ce-que ça donne "select * from pg_class where relfilenode =1292752;"
Hors ligne
# select * from pg_class where relfilenode =1292752;
relname | relnamespace | reltype | relowner | relam | relfilenode | reltablespace | relpages | reltuples | reltoastrelid | reltoastidxid | relhasindex | relisshared
| relistemp | relkind | relnatts | relchecks | relhasoids | relhaspkey | relhasrules | relhastriggers | relhassubclass | relfrozenxid | relacl
| reloptions
----------------------+--------------+---------+----------+-------+-------------+---------------+----------+-----------+---------------+---------------+-------------+-------------
+-----------+---------+----------+-----------+------------+------------+-------------+----------------+----------------+--------------+--------------------------------------------
--+------------
ptg_pers_test_id_seq | 17859 | 1292753 | 10 | 0 | 1292752 | 0 | 1 | 1 | 0 | 0 | f | f
| f | S | 10 | 0 | f | f | f | f | f | 0 | {postgres=rwU/postgres,basic_geo=U/postgres
} |
(1 row)
Hors ligne
est-ce-que tes données viennent d'une replication, si c'est le cas verifie que la deuxième base à les me^mes fichiers WAL que la première.
Hors ligne
Non, ce n'est pas une base répliquée.
Hors ligne
tu n'as pas par hasard créer la sequence et en meme temps declaré le champs comme serial?
Hors ligne
Postgres.0,
Voici les commandes exécutées pour la création des structures :
CREATE TABLE ptg_pers_test (
id SERIAL,
....
....
);
ALTER TABLE ptg_pers_test ADD CONSTRAINT pk_ptg_pers_test PRIMARY KEY(id);
Je répond un peu rapidement mais j'essaye d'être réactif, désolé.
Hors ligne
En général quand tu change de session Postgres n'est plus capable de trouver les fichiers de données dans la session courrante.
Peus-tu décrire brievement le code qui plante?
Dernière modification par Postgres.0 (26/11/2012 18:06:51)
Hors ligne
Re,
Alors, notre DBA Oracle, qui suit également PostgreSQL, a fait un TOUCH sur le fichier 1292752.
La séquence semble avoir "retrouvé ses petits".
Nous avons de nouveau accès à la séquence sous PgAdmin.
Elle s'incrémente correctement et les insertions en base sont reparties.
Sinon, pour infos, la table avec la pk qui fait appel à la séquence existent depuis la création de la base (aucune modif structurelle).
L'outil qui fait l'alimentation de la table n'a pas non plus subit de modifications dernièrement.
Hier, un autovacuum full + reindex full, sans anomalies.
Nous sommes à la recherche de l'origine du problème.
Je reviens sur le post si nous trouvons quelque chose.
Merci pour ton aide.
Hors ligne
Bonjour à tous,
Nous avons trouvé l'origine du problème : c'est l'antivirus Kaspersky qui a détecté un virus "Virus.DOS.SillyC.345" et qui a mis en quarantaine le fichier 1292752.
Problème, il a recommencé hier soir avec un autre fichier 18075 (autre séquence).
Notre DBA Oracle n'est pas arrivé, savez-vous comment on utilise la commande TOUCH pour recréer le fichier ?
Il semble que ce soit des fichiers binaires.
Cette solution semble avoir réglé notre problème hier.
Est-ce la bonne solution ?
Merci pour votre aide.
Hors ligne
Rebonjour,
Il semble que les 2 commandes suivantes réglent le problème :
touch /home/postgres/PG_DATA/17855/18075
chmod 600 /home/postgres/PG_DATA/17855/18075
Apparemment, mais dites moi si je me trompe, PostgreSQL semble avoir les infos en mémoire et être capable de réecrire le contenu du fichier.
Reste à savoir, si cela est vrai, quels autres fichiers peuvent être impactés ?
Y a t'il un moyen d'extraire tous les relfinodes de la base de données par requête, pour ensuite vérifier l'existence des fichiers ?
Hors ligne
Non, ce n'est clairement pas la bonne solution. Dans le cas des séquences, ce n'est pas trop grave car il est possible de la réinitialiser. Par contre, s'il s'agit d'une table, vous perdriez toutes les données. En fait, il faut arrêter PostgreSQL, récupérer le fichier mis en quarantaine, le remettre au bon endroit, faire une sauvegarde de toutes les bases, recréer le répertoire des données et restaurer les bases. Et configurer l'antivirus pour qu'il ne s'occupe pas de ce qui se trouve dans le répertoire des données de PostgreSQL et dans ses tablespaces.
Guillaume.
Hors ligne
Oh et pour répondre à la dernière question, vous n'avez de toute façon pas le choix actuellement. Le mieux est de reconstruire toute la partie PostgreSQL pour s'assurer qu'il n'y a pas une corruption d'autres fichiers PostgreSQL.
Guillaume.
Hors ligne
Bonjour Guillaume,
Pourtant, après la commande TOUCH, plus de messages d'erreur, nous accédons bien aux données, les séquences fonctionnent.
Cela veut-il dire que PostgreSQL à les infos en mémoire ?
Est-ce que lorsque nous allons faire un arrêt/redémarrage nous allons avoir des problèmes ?
Les répertoires de PostgreSQL sont à présent ignorés par l'antivirus.
Nous faisons des exports journaliers de la base de données, en cas de problème de redémarrage, nos exports seront-ils exploitables ? où peut-on rencontrer d'autres problèmes.
Y-a-t'il quelque chose à faire avant l'arrêt/redémarrage pour pouvoir réagir à un éventuel problème ?
Merci pour votre aide.
Hors ligne
PostgreSQL conserve certaines données en cache mais tout ne tient pas en cache. De plus, il y a très peu d'informations dans une séquence.
Concernant l'arrêt/redémarrage, pour la séquence, je ne pense pas. Par contre, rien ne dit qu'il n'y a pas eu d'autres corruptions occasionnées par l'antivirus. Mais ça, même sans arrêt/redémarrage, s'il y a eu corruption, vous êtes impacté.
Les exports doivent être utilisables si leur création n'a pas posé de problème. Sauf cas vraiment particulier de corruption, mais c'est facile à tester avec une simple restauration.
Guillaume.
Hors ligne
Ok, trés bien.
Nous allons essayer de programmer une coupure du service, faire un export puis un arrêt/redémarrage et voir ce qu'il y a lieu de faire.
Merci Guillaume.
Hors ligne
Pages : 1
