Corruption du fichier Data - mauvaise gestion des grosses tables?

Bonjour,

Je suis confronté à un problème très embêtant.
J’ai une base de donnée qui contient actuellement 76 millions d’enregistrements répartis sur 50 tables dont une douzaine qui concentrent 90% du volume global.

J’avais une une table qui comportait 25 millions encore en plus, ainsi que encore une autre de 13 millions. Donc un total global de plus de 100 millions d’enregistrements…
J’ai fait un gros traitement sur ces deux tables et j’ai du supprimer tous les enregistrements de ces deux tables.
La suppression des 25+13 millions enregistrements s’est faite apparemment sans problème ni erreur.
Ces tables apparaissent maintenant à zéro enregistrements. Tout semblait donc normal.

Sauf que ! Lorsque je refait un nouveau traitement de recherche de quelques nouvelles fiches sur ces 2 tables, j’ai une recherche séquentiel sur 25 millions d’enregistrement qui apparaît (et qui dure quelques secondes) comme si il y avait encore la totalité des enregistrements, ce qui est faux il n’y a que quelques nouvelles fiches.

Voyant ça, j’ai compacté la base, recréer les index et pour finir j’ai vérifié (aucune erreur détectée) puis réparé, réindexé toute la base.
Résultat : toujours la même chose ! Il continue de faire une recherche séquentielle sur 25 millions de fiches alors qu’il n’y a que 20 nouvelles fiches dans cette base fraîchement reconstruite.

C’est très embêtant car je dois absolument relancer un gros calcul qui va rechercher et recréer des millions de fiches dans ces 2 tables, mais c’est impossible à faire si chaque requête passe 30 secondes à balayer séquentiellement 25 millions de fiches fantômes…

Quelqu’un à déjà eu ça ?
Qu’en pensez vous ?
Que dois-je faire ?

Merci de votre retour

Bonsoir Florent,
tu ne précises pas si le CSM a contrôlé la structure et data, et ce qu’il en dit. En supposant que c’est fait et qu’il dise que tout va bien, je me demande si le data n’est pas vérolé - ça ne m’est arrivé qu’une fois mais ça ne s’oublie pas. Je m’en était sorti en exportant la base avec SQL EXPORTER BASE, puis réimport de tout ça dans un data “vierge” avec SQL EXECUTER SCRIPT. On peut aussi faire cet export import avec des ENVOYER ENREGISTREMENT en source et RECEVOIR ENREGISTREMENT en cible.

Ha si, il y a une autre piste, aussi, c’est le réglage Enregistrement(s) définitivement supprimé(s) ; par contre je n’y ai jamais rien compris et ne m’en sers pas, je suis incapable de dire si ça joue en cas de compactage.

Oui c’est normal, il faut faire un compactage avancé avec les options “Force updating records” et “compact address table” coché. Une simple suppression de records, pour des questions d’optimisations ne supprime pas les reference dans la table d’adresse. Il faut donc faire un compactage de la table d’adresse.

Bonjour

Suite de mes investigations.
Pour répondre à une première interrogation, la vérification des données par le CSM ne donnait aucune erreur.
Il me semble bien que j’avais lancé un compactage avec l’option de reconstruction de la table d’adresse mais avec toujours le problème persistant.
Du coup, j’ai codé une moulinette d’import / export par des “envoyer enregistrement” de toute ma base.
Malgré le volume des données cela à été assez rapide.
J’ai tout réimporté dans une base vierge.
Il a fallu aussi faire une autre moulinette pour mettre à jour les numéros de clefs primaires de chaque table qui ne correspondaient pas avec les données importées.

Résultat : nickel chrome !!
Tout est reparti sur de bonnes bases !!

Je me dis d’ailleurs que je lancerai régulièrement un export global de mes tables avec cette méthode pour me faire une sauvegarde complémentaire aux autres types de sauvegardes déjà en route.

Mon expérience prouve qu’il vaut mieux multiplier les sauvegardes et leurs types…

Merci