Que donne Berkeley DB en cas de kill -9 ou de debranchement intempestif
de la machine pendant les accès à la base? Je suppose que la base peut
être corrompue? Si oui, existe-t-il un moyen de verifier l'integrité
d'une base DB quand on l'ouvre?
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
DINH Viêt Hoà
Que donne Berkeley DB en cas de kill -9 ou de debranchement intempestif de la machine pendant les accès à la base? Je suppose que la base peut être corrompue? Si oui, existe-t-il un moyen de verifier l'integrité d'une base DB quand on l'ouvre?
version 1 => base corrompue C'est la version 1 qui est en standard sur les différents Unix :)
A partir de je ne sais plus quelle version, la base de donnée est censée être journalisée, donc, moins de corruption de la base.
-- DINH V. Hoa,
"elle est maquillée comme une voiture volée" -- Elisa
Que donne Berkeley DB en cas de kill -9 ou de debranchement intempestif
de la machine pendant les accès à la base? Je suppose que la base peut
être corrompue? Si oui, existe-t-il un moyen de verifier l'integrité
d'une base DB quand on l'ouvre?
version 1 => base corrompue
C'est la version 1 qui est en standard sur les différents Unix :)
A partir de je ne sais plus quelle version, la base de donnée est censée
être journalisée, donc, moins de corruption de la base.
--
DINH V. Hoa,
"elle est maquillée comme une voiture volée" -- Elisa
Que donne Berkeley DB en cas de kill -9 ou de debranchement intempestif de la machine pendant les accès à la base? Je suppose que la base peut être corrompue? Si oui, existe-t-il un moyen de verifier l'integrité d'une base DB quand on l'ouvre?
version 1 => base corrompue C'est la version 1 qui est en standard sur les différents Unix :)
A partir de je ne sais plus quelle version, la base de donnée est censée être journalisée, donc, moins de corruption de la base.
-- DINH V. Hoa,
"elle est maquillée comme une voiture volée" -- Elisa
manu
DINH Viêt Hoà wrote:
Que donne Berkeley DB en cas de kill -9 ou de debranchement intempestif de la machine pendant les accès à la base? Je suppose que la base peut être corrompue? Si oui, existe-t-il un moyen de verifier l'integrité d'une base DB quand on l'ouvre?
version 1 => base corrompue C'est la version 1 qui est en standard sur les différents Unix :)
Oui, et c'est celle que j'utilise. Donc deuxième question: ai-je un moyen de verifier la bonne santé de la base? Si je peux la parcourir entièrement avec db->seq, ca me donne une bonne garantie sur la structure de la base, mais est-ce que ca suffit pour être sur que les données sont correctes?
En fait, l'idée, c'est que j'ai un dump au format texte qui est fait regulièrement, donc si la base est corrompue, je repars du fichier texte. Mais pour faire ca il faut être capable de detecter la corruption.
Si il n'y a pas de garantie sur l'etat des données, j'immagine que le seul moyen d'en sortir, c'est de parcourir regulièrement la base et de maintenir un fichier auxilaire où je stocke un checksum des données: si au démarrage le checksum n'est pas verifié, c'est que la base est sale, et que je dois recharger le fichier texte.
Cette approche est-elle envisageable? Ai-je des alternatives?
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:
Que donne Berkeley DB en cas de kill -9 ou de debranchement intempestif
de la machine pendant les accès à la base? Je suppose que la base peut
être corrompue? Si oui, existe-t-il un moyen de verifier l'integrité
d'une base DB quand on l'ouvre?
version 1 => base corrompue
C'est la version 1 qui est en standard sur les différents Unix :)
Oui, et c'est celle que j'utilise. Donc deuxième question: ai-je un
moyen de verifier la bonne santé de la base? Si je peux la parcourir
entièrement avec db->seq, ca me donne une bonne garantie sur la
structure de la base, mais est-ce que ca suffit pour être sur que les
données sont correctes?
En fait, l'idée, c'est que j'ai un dump au format texte qui est fait
regulièrement, donc si la base est corrompue, je repars du fichier
texte. Mais pour faire ca il faut être capable de detecter la
corruption.
Si il n'y a pas de garantie sur l'etat des données, j'immagine que le
seul moyen d'en sortir, c'est de parcourir regulièrement la base et de
maintenir un fichier auxilaire où je stocke un checksum des données: si
au démarrage le checksum n'est pas verifié, c'est que la base est sale,
et que je dois recharger le fichier texte.
Cette approche est-elle envisageable? Ai-je des alternatives?
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Que donne Berkeley DB en cas de kill -9 ou de debranchement intempestif de la machine pendant les accès à la base? Je suppose que la base peut être corrompue? Si oui, existe-t-il un moyen de verifier l'integrité d'une base DB quand on l'ouvre?
version 1 => base corrompue C'est la version 1 qui est en standard sur les différents Unix :)
Oui, et c'est celle que j'utilise. Donc deuxième question: ai-je un moyen de verifier la bonne santé de la base? Si je peux la parcourir entièrement avec db->seq, ca me donne une bonne garantie sur la structure de la base, mais est-ce que ca suffit pour être sur que les données sont correctes?
En fait, l'idée, c'est que j'ai un dump au format texte qui est fait regulièrement, donc si la base est corrompue, je repars du fichier texte. Mais pour faire ca il faut être capable de detecter la corruption.
Si il n'y a pas de garantie sur l'etat des données, j'immagine que le seul moyen d'en sortir, c'est de parcourir regulièrement la base et de maintenir un fichier auxilaire où je stocke un checksum des données: si au démarrage le checksum n'est pas verifié, c'est que la base est sale, et que je dois recharger le fichier texte.
Cette approche est-elle envisageable? Ai-je des alternatives?
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
DINH Viêt Hoà
DINH Viêt Hoà wrote:
Que donne Berkeley DB en cas de kill -9 ou de debranchement intempestif de la machine pendant les accès à la base? Je suppose que la base peut être corrompue? Si oui, existe-t-il un moyen de verifier l'integrité d'une base DB quand on l'ouvre?
version 1 => base corrompue C'est la version 1 qui est en standard sur les différents Unix :)
Oui, et c'est celle que j'utilise. Donc deuxième question: ai-je un moyen de verifier la bonne santé de la base? Si je peux la parcourir entièrement avec db->seq, ca me donne une bonne garantie sur la structure de la base, mais est-ce que ca suffit pour être sur que les données sont correctes?
En fait, l'idée, c'est que j'ai un dump au format texte qui est fait regulièrement, donc si la base est corrompue, je repars du fichier texte. Mais pour faire ca il faut être capable de detecter la corruption.
Si il n'y a pas de garantie sur l'etat des données, j'immagine que le seul moyen d'en sortir, c'est de parcourir regulièrement la base et de maintenir un fichier auxilaire où je stocke un checksum des données: si au démarrage le checksum n'est pas verifié, c'est que la base est sale, et que je dois recharger le fichier texte.
Cette approche est-elle envisageable? Ai-je des alternatives?
heu ... et pourquoi tu mets pas un espèce de fichier genre :
- ta base : ma-base.db - utilisation base : ma-base.db.corrupted -
sur les BSD, comme la création de fichier est atomique me semble-t-il, tu es garanti que si le fichier corrupted est présent, ta base est en cours d'utilisation. Si au prochain lancement de ton appli, ce fichier est présent, et bien tu flushes ta base.
Ca te va ?
(un peu comme les fichiers dot lock en fait ... (/var/mail/toto.lock), sauf que là, ce serait plus pour un rôle d'état de la base)
-- DINH V. Hoa,
"j'ai du boulot je peux pas venir" -- cege
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:
Que donne Berkeley DB en cas de kill -9 ou de debranchement intempestif
de la machine pendant les accès à la base? Je suppose que la base peut
être corrompue? Si oui, existe-t-il un moyen de verifier l'integrité
d'une base DB quand on l'ouvre?
version 1 => base corrompue
C'est la version 1 qui est en standard sur les différents Unix :)
Oui, et c'est celle que j'utilise. Donc deuxième question: ai-je un
moyen de verifier la bonne santé de la base? Si je peux la parcourir
entièrement avec db->seq, ca me donne une bonne garantie sur la
structure de la base, mais est-ce que ca suffit pour être sur que les
données sont correctes?
En fait, l'idée, c'est que j'ai un dump au format texte qui est fait
regulièrement, donc si la base est corrompue, je repars du fichier
texte. Mais pour faire ca il faut être capable de detecter la
corruption.
Si il n'y a pas de garantie sur l'etat des données, j'immagine que le
seul moyen d'en sortir, c'est de parcourir regulièrement la base et de
maintenir un fichier auxilaire où je stocke un checksum des données: si
au démarrage le checksum n'est pas verifié, c'est que la base est sale,
et que je dois recharger le fichier texte.
Cette approche est-elle envisageable? Ai-je des alternatives?
heu ... et pourquoi tu mets pas un espèce de fichier genre :
- ta base : ma-base.db
- utilisation base : ma-base.db.corrupted
-
sur les BSD, comme la création de fichier est atomique me semble-t-il,
tu es garanti que si le fichier corrupted est présent, ta base est en
cours d'utilisation. Si au prochain lancement de ton appli, ce fichier
est présent, et bien tu flushes ta base.
Ca te va ?
(un peu comme les fichiers dot lock en fait ... (/var/mail/toto.lock),
sauf que là, ce serait plus pour un rôle d'état de la base)
Que donne Berkeley DB en cas de kill -9 ou de debranchement intempestif de la machine pendant les accès à la base? Je suppose que la base peut être corrompue? Si oui, existe-t-il un moyen de verifier l'integrité d'une base DB quand on l'ouvre?
version 1 => base corrompue C'est la version 1 qui est en standard sur les différents Unix :)
Oui, et c'est celle que j'utilise. Donc deuxième question: ai-je un moyen de verifier la bonne santé de la base? Si je peux la parcourir entièrement avec db->seq, ca me donne une bonne garantie sur la structure de la base, mais est-ce que ca suffit pour être sur que les données sont correctes?
En fait, l'idée, c'est que j'ai un dump au format texte qui est fait regulièrement, donc si la base est corrompue, je repars du fichier texte. Mais pour faire ca il faut être capable de detecter la corruption.
Si il n'y a pas de garantie sur l'etat des données, j'immagine que le seul moyen d'en sortir, c'est de parcourir regulièrement la base et de maintenir un fichier auxilaire où je stocke un checksum des données: si au démarrage le checksum n'est pas verifié, c'est que la base est sale, et que je dois recharger le fichier texte.
Cette approche est-elle envisageable? Ai-je des alternatives?
heu ... et pourquoi tu mets pas un espèce de fichier genre :
- ta base : ma-base.db - utilisation base : ma-base.db.corrupted -
sur les BSD, comme la création de fichier est atomique me semble-t-il, tu es garanti que si le fichier corrupted est présent, ta base est en cours d'utilisation. Si au prochain lancement de ton appli, ce fichier est présent, et bien tu flushes ta base.
Ca te va ?
(un peu comme les fichiers dot lock en fait ... (/var/mail/toto.lock), sauf que là, ce serait plus pour un rôle d'état de la base)
-- DINH V. Hoa,
"j'ai du boulot je peux pas venir" -- cege
manu
DINH Viêt Hoà wrote:
heu ... et pourquoi tu mets pas un espèce de fichier genre :
- ta base : ma-base.db - utilisation base : ma-base.db.corrupted -
sur les BSD, comme la création de fichier est atomique me semble-t-il, tu es garanti que si le fichier corrupted est présent, ta base est en cours d'utilisation. Si au prochain lancement de ton appli, ce fichier est présent, et bien tu flushes ta base.
Ca te va ?
En fait je me dis qu'en mettant simplement un fichier ma-base.busy que je detruit dans une fonction atexit, je n'ai qu'à tester l'existance du fichier pour savoir si la base est potentiellement corrompue ou pas.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:
heu ... et pourquoi tu mets pas un espèce de fichier genre :
- ta base : ma-base.db
- utilisation base : ma-base.db.corrupted
-
sur les BSD, comme la création de fichier est atomique me semble-t-il,
tu es garanti que si le fichier corrupted est présent, ta base est en
cours d'utilisation. Si au prochain lancement de ton appli, ce fichier
est présent, et bien tu flushes ta base.
Ca te va ?
En fait je me dis qu'en mettant simplement un fichier ma-base.busy que
je detruit dans une fonction atexit, je n'ai qu'à tester l'existance du
fichier pour savoir si la base est potentiellement corrompue ou pas.
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
heu ... et pourquoi tu mets pas un espèce de fichier genre :
- ta base : ma-base.db - utilisation base : ma-base.db.corrupted -
sur les BSD, comme la création de fichier est atomique me semble-t-il, tu es garanti que si le fichier corrupted est présent, ta base est en cours d'utilisation. Si au prochain lancement de ton appli, ce fichier est présent, et bien tu flushes ta base.
Ca te va ?
En fait je me dis qu'en mettant simplement un fichier ma-base.busy que je detruit dans une fonction atexit, je n'ai qu'à tester l'existance du fichier pour savoir si la base est potentiellement corrompue ou pas.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Laurent Wacrenier
DINH Viêt Hoà écrit:
A partir de je ne sais plus quelle version, la base de donnée est censée être journalisée, donc, moins de corruption de la base.
Ça n'empeche que le décompte des vérous peut être faux.
DINH Viêt Hoà <dinh.viet.hoa@free.fr> écrit:
A partir de je ne sais plus quelle version, la base de donnée est censée
être journalisée, donc, moins de corruption de la base.
Ça n'empeche que le décompte des vérous peut être faux.
