Utilitaires de réparation : on est toujours chez "guignol" !

[papo4334]

Contexte : aucun problème d'utilisation identifié depuis le passage en G2026 v2.0 ; généalogie d'environ 49 000 individus ; mais envie de prendre un maximum de précaution après la création ou modification de ~300 fiches et avant de poursuivre ;

A noter : après chaque longue séance de travail, je lance la procédure des 5 clicks ; environ 1 fois sur 2 , elle se contente de vérifier avant de notifier "aucun problème d'index" , sinon elle passe par une (courte) phase de génération d'index avant d'arriver au même "aucun problème d'index". Ceci tend à prouver qu'en quelques heures de travail (simple) les index ne sont pas parfaits environ une fois sur deux et qu'il semble donc sage d'y remédier assez fréquemment.

Déroulement des tentatives successives de réparation

1. lancement de Utilitaires/ Maintena... /Réparer la base de données / Réparation niveau 2 (recommandé) --> échec avec une notification du genre "impossible de réparer ; passer à un niveau de réparation supérieur."
2. lancement de Utilitaires/ Maintena... /Réparer la base de données / Regénérer la base de donnée --> plantage du processus G2026 (exception xxxx - pas notée en pensant recommencer et prendre une copie d'écran)
3. lancement de Utilitaires/ Maintena... /Restructurer un dossier généalogique / Réindexation --> OK
4. lancement de Utilitaires/ Maintena... /Restructurer un dossier généalogique / Réenregistrement avec classement et symétrie --> OK
5. lancement de Utilitaires/ Maintena... /Restructurer un dossier généalogique / Réparation, Réenregistrement avec classement et symétrie --> OK
6. lancement de Utilitaires/ Maintena... /Réparer la base de données / Réparation niveau 2 (recommandé) --> OK
7. lancement de Utilitaires/ Maintena... /Réparer la base de données / Regénérer la base de donnée --> OK

Avec un peu de chance je dispose donc maintenant d'une base que G2026 considère comme saine.

Je laisse aux experts et même plutôt au CDIP comprendre la chose.

Faut il, pour nous utilisateurs, en déduire :

• que même en l'absence de tout symptôme on peut avoir une base/généalogie dans un état "mauvais" au point de faire échouer voire planter les utilitaires de réparation
• qu'il est donc prudent de procéder très fréquemment à de la maintenance de la base de donnée
• qu'il semble recommandé de commencer systématiquement par une restructuration (au moins niveau 2) et pour se garantir au mieux, enchainer avec une réparation avec "régénération de la base de donnée"

Nota : au cas où le CDIP veuille vraiment se pencher sur ces problèmes, je tiens à disposition diverses sauvegardes (dont celle de la généalogie qui fait planter l'utilitaire de réparation/régénération)

 

[AL1493]

lancement de Utilitaires/ Maintena... /Réparer la base de données / Réparation niveau 2 (recommandé) --> échec avec une notification du genre "impossible de réparer ; passer à un niveau de réparation supérieur."

Bonjour,
Il me semble qu'il a souvent été écrit sur ce forum que le mieux était de commencer par la restructuration Réenregistrement avec classement et symétrie et en général c'est suffisant. D'ailleurs votre étape 5 semble bien le confirmer (attention au vocabulaire, c'est Restructuration, pas Réparation.
Même si avec G2026, il semble que la Réparation niveau 2 soit performante, je pense qu'elle ne sait pas corriger les problèmes d'index, mais elle n'est peut-âtre pas faite pour cela.
Depuis 1999, j'ai dû utiliser 4 ou 5 fois les réparations, mais je fais très régulièrement des Restructurations, et j'ai très peu de problèmes avec ma base de données
Je ne suis pas certain qu'il faille réaliser toutes ces restructuration, réparations, régénération systématiquement.

que même en l'absence de tout symptôme on peut avoir une base/généalogie dans un état "mauvais" au point de faire échouer voire planter les utilitaires de réparation

Je pense que quand on voit des "symptômes", c'est qu'il y a déjà plusieurs erreurs qui se cumulent, et donc plus difficiles à corriger.

qu'il semble recommandé de commencer systématiquement par une restructuration (au moins niveau 2) et pour se garantir au mieux, enchainer avec une réparation avec "régénération de la base de donnée"

C'est mon avis et mon expérience, mais pas la peine de faire de réparation ou de régénération.

 

[Deleau]

Personnellement, si je n'ai pas de défauts, je n'utilise pas ces outils.
Seule exception, due à l'expérience, après une importation et fusion de fiches, je passe l'utilitaire de restructuration (avec classement et symétrie).

Cela fait plus de 10 ans que je travaille de cette manière et jamais eu de soucis de base de données.
Je pars du principe que lorsque tout fonctionne normalement, il ne faut pas chercher d'emmerdements.

NOTE : je n'ai qu'une petite base de données, un peu moins de 4000 personnes, je laisse le soin aux possesseurs de très grosses bases d'apporter leurs propres commentaires/expériences

 

[papo4334]

@AL1493 : désolé d'insister mais je maintiens que ce qui est proposé au plus haut niveau de "restructuration" est bien : Réparation, Réenregistrement avec classement et symétrie (cf. capture d'écran jointe).

Ceci étant dit le vocabulaire choisi par le CDIP est , pour moi, secondaire.
Ce qui ne l'est pas c'est l'absence (à ma connaissance) d'un manuel (ou chapitre de) indiquant i) ce que fait chacun des utilitaires et ii) pourquoi et quand en utiliser un et lequel (ou quel enchainement).

@Deleau : ce que prouve ma série de tests, c'est que (au delà des index qu'il faut remettre au carré après quelques heures de travail) même quand on ne constate aucun dysfonctionnement lors d'une utilisation classique du logiciel, il arrive (AMHA souvent) que la base soit corrompue (au point de faire dérailler voire planter ses propres utilitaires de réparation). Quand on est conscient de la chose (probabilité très forte de base corrompue après quelques jours de travail), il me parait normal (au delà de fréquentes sauvegardes) d'essayer les outils de maintenance proposés par le logiciel.

Nous sommes donc confrontés à un double problème

• une base de donnée qui ne tient pas la route : ie. les fonctions basiques de gestion d'une généalogie (je ne parle pas ici ni d'import, ni de fusion ou autre fonctions complexes) n'arrivent pas à s'effectuer sans provoquer des problèmes dans la base de donnée
• des outils de restructuration/réparation très mal documentés et eux mêmes buggués.

AMHA la véritable solution résiderait/résidera dans un abandon de la mécanique base de donnée actuelle (qui à force d'évolutions ajouts et compléments arrive à bout de souffle et, manifestement, n'est même plus maitrisée par les développeurs) et une migration vers une solution éprouvé du genre PostgreSQL (ou autre équivalent). Je comprend bien que cela représente un travail énorme en plus du coup de blues de devoir abandonner "son bébé", mais plus le CDIP retarde cette migration plus elle deviendra difficile ; c'est portant une question de survie du logiciel sur le PC face aux services Web de gestion de généalogies.

 

[AL1493]

désolé d'insister mais je maintiens que ce qui est proposé au plus haut niveau de "restructuration" est bien : Réparation, Réenregistrement avec classement et symétrie (cf. capture d'écran jointe).

Vous avez raison, je l'avais oublié, je n'utilise que la 2ème option.
J'ai dû utiliser une fois cette "réparation, réenregistrement " qui a planté.

Il est vrai qu'on s'y perd un peu avec tous ces outils qui maintiennent, réparent, restructurent, sans trop savoir dans quel ordre les utiliser.
Je pense que le problème, c'est que chacun des outils répare un problème particulier et que si on les enchaîne dans le mauvais ordre, on fait peut-être plus de dégâts.
Je n'utilise pas l'optimisation e la base de donnée, car les quelques fois où je l'ai utilisée, plantage.

 

[Deleau]

Nous sommes donc confrontés à un double problème

• une base de donnée qui ne tient pas la route : ie. les fonctions basiques de gestion d'une généalogie (je ne parle pas ici ni d'import, ni de fusion ou autre fonctions complexes) n'arrivent pas à s'effectuer sans provoquer des problèmes dans la base de donnée

Je ne suis pas d'accord avec vous sur ce point, je n'ai jamais rencontré de soucis majeurs dans la gestion de mes bases de données.

Par contre, oui, je suis d'accord qu'il faudrait évoluer vers un autre type de base de donnée (comme le PostGreSQL par exemple) mais peut être pas pour les mêmes raisons, en effet je pense qu'il n'y a pas de concurrence entre une application telle que Généatique et des solutions en ligne.

• des outils de restructuration/réparation très mal documentés et eux mêmes buggués.

1 - D'accord sur le fait que ces outils ne sont pas documentés (pas très mal mais pas du tout).
2 - On ne peux pas affirmer que ces outils sont buggués parceque vous avez rencontré des difficultés, moi par exemple je n'en ai pas (j'ai essayé ces outils sur des copies de mes bases de données). Mais je ne peux pas affirmer non plus qu'ils ne le sont pas dans certains cas particuliers (en particulier sur de tres grosses bases).

 

[papo4334]

C'est pourtant bien un bug de l'utilitaire "Régénérer la base de donnée" qui provoque un crash du process G2026 de type "exception error" (en laissant les fichiers temporaires dans un état inconnu). Il eut été décevant mais acceptable de recevoir une notification d'impossibilité d'effectuer la fonction, et une terminaison propre.

Heureusement lors de son second lancement la fonction s'est aperçu de l'existence du fichier temporaire de réparation (...rpr...) et m'a proposé de le supprimer avant d'en créer un autre, mais je n'ai pas la moindre idée s'il n'existe pas dans le xxx.gwa d'autres fichiers temporaires résiduels.

 

[PUNSOLA]

Par contre, oui, je suis d'accord qu'il faudrait évoluer vers un autre type de base de donnée (comme le PostGreSQL par exemple) mais peut être pas pour les mêmes raisons, en effet je pense qu'il n'y a pas de concurrence entre une application telle que Généatique et des solutions en ligne.

Il vaut mieux utiliser une base embarquée comme Sqlite (la base la plus utilisée au monde, présente dans tous les téléphones Android).
PostGreSQL est une très bonne base mais plutôt réservée à un usage professionnel car il faut lancer des programmes en arrière-plan. Ce n'est pas le cas pour Sqlite, qui est très simple : la base est contenue dans un seul fichier, qui est lu par un programme inclus dans le logiciel qui l'utilise. C'est de plus une base assez performante (si les requêtes pour y accéder sont bien faites), assez robuste, et ne nécessitant pas de restructuration périodique si la conception des données est bien faite.

 

[papo4334]

En prenant en compte qu'il existe sous Généatique des généalogies avec plus de 700 000 personnes et le nombre d'attributs, relations, évènements, marqueurs, ... utilisables, est ce que Sqlite (et son fichier unique) serait à la hauteur ?

 

[predigny]

Ce n'est pas un problème de la base de données mais un, ou plutôt des problèmes de contrôle de cette base par le programme. Le cdip très souvent identifie une faille de contrôle de cette base et la corrige ; il y en a de moins en moins mais il est probable qu'il en reste encore, alors selon la façon dont les utilisateurs utilisent Généatique certaines failles apparaissent encore. Et il n'y a pas que la base de données qui est en cause, si une fonction fait planter le programme (pour N raisons) alors la base de données n'est pas fermée correctement et à l'ouverture suivante il peut y avoir un index "cassé" mais c'est alors une Réindexation qu'il faut faire, pas une réparation car si l'index est cassé la réparation peut mal se passer.

 

[PUNSOLA]

En prenant en compte qu'il existe sous Généatique des généalogies avec plus de 700 000 personnes et le nombre d'attributs, relations, évènements, marqueurs, ... utilisables, est ce que Sqlite (et son fichier unique) serait à la hauteur ?

Oui. La contrainte vient surtout du fait de créer les bons index et de la façon d'écrire les requêtes. Il faut tester les requêtes sur une grosse base (700 000). Une requête peu performante car trop complexe pourra toujours devenir performante si on la décompose.

 

[papo4334]

Si vraiment SQLite peut satisfaire les besoins des plus grosses généalogies, ce serait parfait pour une migration, sachant que puisque Généatique tient à jour le nombre de fiches modifiées ou créées il serait facile que lors de la fermeture ou de l'ouverture, le logiciel lance automatiquement les utilitaires de vérification d'intégrité (PRAGMA -au moins quick_check) et de maintenance optimisation (genre REINDEX ou VACCUUM)

 

[papo4334]

Ce n'est pas un problème de la base de données mais un, ou plutôt des problèmes de contrôle de cette base par le programme. Le cdip très souvent identifie une faille de contrôle de cette base et la corrige ; il y en a de moins en moins mais il est probable qu'il en reste encore, alors selon la façon dont les utilisateurs utilisent Généatique certaines failles apparaissent encore. Et il n'y a pas que la base de données qui est en cause, si une fonction fait planter le programme (pour N raisons) alors la base de données n'est pas fermée correctement et à l'ouverture suivante il peut y avoir un index "cassé" mais c'est alors une Réindexation qu'il faut faire, pas une réparation car si l'index est cassé la réparation peut mal se passer.

Désolé de, pour une fois, ne pas partager votre analyse et son optimisme sur la maitrise de la gestion de la base de donnée par les développeurs.

Depuis le passage en v2.0 je n'ai eu aucun plantage ni arrêt intempestif du process Généatique, et je n'ai lancé aucune action considérée comme "à risque" (du genre, import, fusion, ...) et pourtant

• en moyenne après 50 à 100 modifications de fiches, la procédure "5-clicks" entraine une phase de ré indexation (ce qui prouve bien que cette fonction considère que les index méritent d'être remis au carré). C'est énorme et prouve que la base de donnée est mal gérée par les fonctions de base du logiciel.
• Après seulement quelques semaines après toutes les vérifications que ma base était saine et intègre, le fait que la fonction "Réparation de niveau 2" signale qu'elle est incapable de s'exécuter et que le la fonction " Regénération de la base de donnée" provoque un plantage du processus, prouve bien que l'utilisation normale de G2026 à provoqué des problèmes majeurs de la base.

A mes yeux il est évident que le problème majeur de Généatique est son son système de gestion de base de données et qu'il est plus que temps de reprendre la chose de fond en comble.

Un excellent juge de paix entre nos appréciations divergentes, serait de demander aux utilisateurs (ceux qui ne rencontrent aucun dysfonctionnement) de lancer i) la procédure "5-clicks" puis ii) la fonction de "réparation niveau 2"
Je suis vraiment près à parier qu'une majorité (de ceux qui pensent leur base saine) observeront "a minima" une phase de génération d'index (pour les "5-clicks") et, pour certains, une détection d'anomalies pour la réparation. Dans les 2 cas c'est une preuve que la base de donnée avait besoin d'une intervention.

 

[Deleau]

Un excellent juge de paix entre nos appréciations divergentes, serait de demander aux utilisateurs (ceux qui ne rencontrent aucun dysfonctionnement) de lancer i) la procédure "5-clicks" puis ii) la fonction de "réparation niveau 2"
Je suis vraiment près à parier qu'une majorité (de ceux qui pensent leur base saine) observeront "a minima" une phase de génération d'index (pour les "5-clicks") et, pour certains, une détection d'anomalies pour la réparation. Dans les 2 cas c'est une preuve que la base de donnée avait besoin d'une intervention.

Preuve que vous n'avez que faire de nos messages, s'ils ne vont pas dans votre sens.

J'utilise assez régulièrement cette procédure des 5 clicks, mais je vous le répète, je n'irai jamais chercher des ennuis là ou il n'y en a pas en utilisant un utilitaire de réparation sur une base saine.

A chacun de voir ce qu'il veut faire, mais faut pas venir se plaindre lorsqu'on est dans l'embarras ensuite.

 

[papo4334]

... en utilisant un utilitaire de réparation sur une base saine.

base saine : c'est votre affirmation, mais pas la réalité !
-- > le résultat de l'exécution des 2 utilitaires de" réparation" a justement démontré que, chez moi au moins, elle ne l'était pas

Et je proposais que chacun fasse honnêtement le test et le constat et permette ainsi de dénombrer le nombre de cas où, bien que sans symptôme, une base généalogique est saine ou ne l'est pas.

 

[PUNSOLA]

Et il n'y a pas que la base de données qui est en cause, si une fonction fait planter le programme (pour N raisons) alors la base de données n'est pas fermée correctement et à l'ouverture suivante il peut y avoir un index "cassé" mais c'est alors une Réindexation qu'il faut faire, pas une réparation car si l'index est cassé la réparation peut mal se passer.

Justement, l'avantage de Sqlite c'est qu'il n'y a pas besoin de faire des procédures de réparation ou de réindexation, car c'est, comme je disais, une base robuste, c'est à dire qu'elle a des mécanismes transactionnels qui évitent les problèmes sur la base en cas de fermeture anormale ou de plantage.

Si on va sur le forum Heredis, qui utilise Sqlite, on constate qu'il y a infiniment moins de problèmes de bases corrompues que sur Généatique.