Discussion :

[engi]

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]

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]

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]

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]

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]

Bonjour,

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]

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é ...

[engi]

après un backup/restore, voila le résultat du gstat :

Database header page information:
Oldest transaction 126
Oldest active 2
Oldest snapshot 2
Next transaction 127

[aieeeuuuuu]

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 !

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à

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

[engi]

Bonjour,

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à

Bonjour aieeeuuuuu,
Si c'est effectivement le cas, comment forcer la fermeture de toutes les transactions pour remettre les compteurs à un niveau cohérent ?
Le backup/restore n'aurait-il pas du le faire ?

[SergioMaster]

Bonjour,

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?

Oui, j'ai été trop pessimiste ou effrayant

Ce qui suit est à prendre avec des pincettes :

En fait si on regarde le GStat après le backup je dirais 2 non fermées (à moins que GSTAT en soit une)
Il serait (très) intéressant de regarder ce que contient la table MON$TRANSACTION , si les transactions sont nommées dans le programme cela donnerait une piste de débogage (ou pas s'il s'agit d'un utilisateur indélicat)
Toujours selon ton dernier GStat je dirais que tu y verras la transaction #126 ou #125

Si c'est effectivement le cas, comment forcer la fermeture de toutes les transactions pour remettre les compteurs à un niveau cohérent ?
Le backup/restore n'aurait-il pas du le faire ?

Oui, si un shutdown de la base de données a été fait avant le backup, sinon AMHA seules les transactions fermées sont "supprimées"


Quant au sweep il faut savoir qu'il se fait aussi au moment d'un backup (il me semble que makowski me l'avait souligné dans une de mes discussions sur ce forum)
sinon, j'en ai discuté ici

[engi]

Pour info, je suis entrain de recenser toutes les utilisations de transactions dans le code source de nos applications et j'ai déjà trouvé des cas où, en cas d'erreur, il se pourrait que la ou les transactions actives ne soient pas refermées correctement.
Je vais donc travailler sur le code et je ferai ensuite le point sur l'évolution des compteurs obtenus avec gstat.
Merci à tous ceux qui ont participé à ce thread.