Base de données qui plante de temps en temps

**engi** · 15/01/2015, 16h38

salut,
je développe une petite application qui stocke sa production de données dans une base de données firebird 2.5.2
de temps en temps, sans que je sache exactement pourquoi, la connexion à la base devient impossible.
dans ce cas, il suffit que je fasse un backup et une restauration de la base pour régler le problème (avec GBAK).
en parallèle, dans le même temps, la base prend beaucoup de volume par rapport à son contenu réel : elle peut atteindre 800 mo et redescendre à 50 mo une fois le backup/restore effectué.
mon application est développée avec c++ builder et j'utilise la collection de composants fibplus pour gérer les connexions et les données.
la base contient une 50taine de tables et à part une ou deux tables qui peuvent contenir beaucoup d'enregistrements (jusqu'à 1,5 million chez un client), il y a assez peu de données dans les autres tables.
je n'arrive pas à déterminer si c'est un problème connu de firebird, si c'est un problème d'utilisation par nos clients ou si c'est un problème de conception et d'utilisation de la base de données.

une idée ?

**SergioMaster** · 15/01/2015, 18h06

Bonjour,

je pense plutôt qu'il s'agit d'un problème de gestion des transactions (ce qui serait confirmé par le grosse croissance puis décroissance de la BDD après restore), la perte de connexion étant peut être due au sweep de la base de données

**alanglet** · 15/01/2015, 18h53

Bonsoir,

Ça peut être un problème de transactions non closes comme le suggère Sergio, mais ça me rappelle aussi un problème signalé http://tracker.firebirdsql.org/browse/CORE-3951 lors de calculs sur les champs blob texte. Certains préconisent même de les remplacer par des varchar(30000).
Gstat devrait vous fournir des informations sur les transactions non commitées. Le sujet a me semble-t-il été abordé lors de discussions sur ce forum, par exemple http://www.developpez.net/forums/d13...que-dur-100-a/

André

**engi** · 16/01/2015, 11h15

Salut, merci pour vos débuts de piste.
Sur une base d'un client que j'ai sous les yeux, voilà les résultat du gstat :
Database header page information:
Flags 0
Checksum 12345
Generation 452113994
Page size 4096
ODS version 11.2
Oldest transaction 84735678
Oldest active 84735679
Oldest snapshot 84735679
Next transaction 452113981
Bumped transaction 1
Sequence number 0
Next attachment ID 27
Implementation ID 26
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Jun 2, 2014 16:51:04
Attributes force write, no reserve

Variable header data:
Sweep interval: 20000
*END*

A vrai dire, je ne sais pas trop comment interpréter la différence entre le paramètre next transaction et le oldest active !

**SergioMaster** · 16/01/2015, 12h11

Bonjour,

si je ne me trompe pas dans mes calculs (et sauf erreur de transcription) cela veut dire qu'il y a 367378308 transactions en cours !!!!!!
là, il y a vraiment un problème !
Soit votre programme gère (très) mal les transactions , soit vous avez eu affaires avec un utilisateur peu scrupuleux adepte du Ctrl+Alt+Suppr "quand ça va pas assez vite" << c'est du vécu, soit encore (toujours du vécu) un problème de réseau ou un problème sur le serveur (encore du vécu sur un processeur défaillant)

faites votre choix !

**alanglet** · 16/01/2015, 14h11

Bonjour,

Envoyé par engi

A vrai dire, je ne sais pas trop comment interpréter la différence entre le paramètre next transaction et le oldest active !

Bizarre en effet que le numéro de la prochaine transaction soit inférieur à celui de la plus ancienne. Surtout que d'après http://stackoverflow.com/questions/2...count-exceeded ce numéro est un entier sur 31 bits qui ne repart pas à zéro automatiquement en cas de dépassement.
Il serait intéressant de revoir les statistiques après un backup/restore pour voir si tout est correctement réinitialisé.

André

**engi** · 16/01/2015, 14h18

SergioMaster : j'arrive au même calcul et c'est effectivement inquiétant.
dans ce cas extrême, je pense quand même avoir affaire à un client peu enclin aux bonnes moeurs informatique mais des retours de plantage nous sont faits régulièrement et je ne me résous pas à l'idée que tous nos clients sont des sauvages.

alanglet : non la prochaine est égale à : 452.113.981 alors que la plus ancienne vaut : 84.735.678 !

je vais tenter de faire le tour complet de notre code source afin de vérifier s'il n'y a pas un soucis en terme de gestion des transactions.

pour mon information personnelle, peut être n'ai je pas bien compris le fonctionnement du sweep.
l'un d'entre vous peut il m'expliquer l'intérêt du sweep interval et de la fonction sweep ?
ce n'est pas le vidage automatique du garbage collector ?
dans notre cas, j'ai l'impression qu'il n'est jamais executé ...

**aieeeuuuuu** · 16/01/2015, 14h28

Bonjour,

Envoyé par SergioMaster

si je ne me trompe pas dans mes calculs (et sauf erreur de transcription) cela veut dire qu'il y a 367378308 transactions en cours !!!!!!
là, il y a vraiment un problème !

Hmmm, je dirai juste qu'il y a une (très) ancienne transaction non fermée, mais pas forcément que toutes les suivantes sont encore active non?
Dans tous les cas, il y a effectivement un problème de ce coté là

Envoyé par alanglet

Bonjour,
Bizarre en effet que le numéro de la prochaine transaction soit inférieur à celui de la plus ancienne. Surtout que d'après

C'est ce qu'il semble au premier abord mais non : next transaction est 5 fois plus grand, avec donc un chiffre de plus

Oldest active 84 735 679
Next transaction 452 113 981