Discussion :

[neuromencien]

Bonjour,

Je travaille sur un projet qui utilise une base Firebird avec une quinzaine de tables. Les plus grosses tables contiennent ~45 000 enregistrements.
Lorsque je fais une suppression des enregistrements contenus dans ces tables, le temps pris peut aller de 1 min 30 à 20 min. Si les enregistrements ont tous été créés d'un coup (par un import) la suppression prend 1 min 30. Si par contre la base à vécu et que les enregistrements ont étés créés sur 15 jours la suppression prend 20 min. Est ce qu'il y a une sorte de "fragmentation" qui pourrait survenir à l'usage et ralentir les suppressions (j'utilise Firebird 2.5.3) ? Si non, est ce que quelqu'un connaîtrait une des causes possible de ces ralentissements et aurait une solution?

Merci d'avance.

[SergioMaster]

Bonjour,

je répondrai que c'est plutôt un problème de transaction(s) mal fermée(s)

Est ce qu'il y a une sorte de "fragmentation" qui pourrait survenir à l'usage et ralentir les suppressions

ces "fragmentations" ce sont les transactions en cours (non "commitées")
une petite stat (gstat) sur la BDD devrait le montrer
voir la discussion http://www.developpez.net/forums/d14...e-temps-temps/ pour info

[neuromencien]

Merci pour ta réponse. J'ai fais un gstat et j'ai ça:

Database "PLANNING_PJ.GDB"
Database header page information:
Flags 0
Checksum 12345
Generation 85
Page size 4096
ODS version 11.2
Oldest transaction 31
Oldest active 74
Oldest snapshot 74
Next transaction 76
Bumped transaction 1
Sequence number 0
Next attachment ID 57
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Jan 16, 2015 16:14:01
Attributes force write

Variable header data:
Sweep interval: 20000
*END*

Au vu de ce que j'ai pu lire sur internet, j'aurais une transaction toujours active (d'id 74)?
Sachant que je fais un backup et un restore de la base avant chaque démarrage du programme, est ce que ça n'aurait pas de toutes façon annulé cette transaction?

[SergioMaster]

Au vu de ce que j'ai pu lire sur internet, j'aurais une transaction toujours active (d'id 74)?

oui

Sachant que je fais un backup et un restore de la base avant chaque démarrage du programme

mais pourquoi diantre ? Cela voudrait dire que c'est une application monoposte ?

est ce que ça n'aurait pas de toutes façon annulé cette transaction?

joker

[neuromencien]

oui

Et comment je peux fermer cette transaction pour vérifier si oui ou non ça va plus vite sans?

mais pourquoi diantre ? Cela voudrait dire que c'est une application monoposte ?

Non il s'agit bien d'une application clients/serveur. Le backup/restore au démarrage sert à compacter la base mais surtout à détecter les corruptions éventuelles en cas de coupure de courant (puisque Firebird ne semble pas avoir de mécanisme de journalisation qui garantis que les données sont toutes écrites ou pas du tout. On s'est déja retrouvés avec des bases corrompues suite à des coupures violentes des serveurs).

[SergioMaster]

Bonjour,

je ne comprend pas vraiment

Le backup/restore au démarrage sert à compacter la base mais surtout à détecter les corruptions éventuelles en cas de coupure de courant (puisque Firebird ne semble pas avoir de mécanisme de journalisation qui garantis que les données sont toutes écrites ou pas du tout. On s'est déja retrouvés avec des bases corrompues suite à des coupures violentes des serveurs).

Mais cela fait plus de 10 ans que je n'ai pas eu un problème avec une base en Production , et encore la dernière fois il s'agissait alors de Interbase 5.5 et un processeur défectueux (surchauffe) du serveur.
une transaction ne "s'arrêtera" que si la base est "éteinte" (shutdown) avant d'être sauvegardée (backup) et restaurée (restore) , bien sur il faudra ensuite redemarré la base.

[neuromencien]

J'ai fais un shutdown et un backup/restore. Le compteur est bien repassé à 1 mais les temps ne s'améliorent pas. Je vais faire des tests avec une base MySQL pour comparaison.

Par contre pour ce qui est des corruptions de base c'est une demande d'un de nos clients qui coupe électriquement les baies lors de ses tests. Mais ça nous à servi dans d'autres cas. Il y a 1 mois j'ai rencontré un cas ou 3 enregistrements d'une table on disparu entre le backup et le restore (pas de bol c'était le compteur d'index JPA et je me suis retrouvé avec des violations de clés primaires). Donc on a bien des corruptions de temps en temps.

Merci pour ton aide.

[SergioMaster]

J'ai fais un shutdown et un backup/restore. Le compteur est bien repassé à 1

CQFD

mais les temps ne s'améliorent pas.

ça par contre c'est totalement anormal maintenant tout dépend de la base, y a t-il des triggers impliqués dans la suppression (BEFORE DELETE, AFTER DELETE)

[neuromencien]

Non, il n'y a pas de trigger. Et on observe que les performances se dégradent au fil du temps. On fait une centaine de milliers de requêtes DELETE. en commitant tous les 10 000 environ. Les 10 000 premières vont vite le 10 000 suivantes moins vite et ainsi de suite. Quand on active les traces on voit que certaines requêtes prennent 0 ms et d'autres 200 ms alors qu'elle sont identiques... Et on a de plus en plus de requêtes à 200 ms au fil du temps.