Thread: [Firebird-fr-support] =?iso-8859-1?q?transaction_bloqu=E9e?=
Brought to you by:
makowski
From: Richard <ri...@ro...> - 2007-10-05 09:19:43
|
Bonjour a tous Je profite qu'il y a un eu d'activit=E9 sur la liste pour vous soumettre un probl=E8me que j'ai en ce moment: gstat -h ask.gdb Database header page information: Flags 0 Checksum 12345 Generation 59844 Page size 4096 ODS version 10.1 Oldest transaction 4628 Oldest active 4629 Oldest snapshot 4629 Next transaction 59838 Bumped transaction 1 Sequence number 0 Next attachment ID 0 Implementation ID 16 Shadow count 0 Page buffers 0 Next header page 0 Le delta entre la transaction la plus ancienne et la prochaine augmente en permanence entre 2 backup/restore, =E0 la fin de la journ=E9e cela peut atteindre plusieurs dizaines de milliers, les perf deviennent inacceptables. D'une part je en sais pas comment interpr=E9ter cela. Je dirais qu'une transaction ne se valide pas. D'autre part comment faire, pour que cette transaction bloquant soit abandonn=E9e automatiquement, qu'elle time out. Merci de vos id=E9es. RM --=20 Richard Moch Traitement Statistique de l'Information 01 42 53 03 39 |
From: Philippe M. <mak...@fi...> - 2007-10-06 18:54:46
|
Le 05/10/2007 11:19, Richard a dit : > Oldest transaction 4628 > Oldest active 4629 > Oldest snapshot 4629 > Next transaction 59838 > > Le delta entre la transaction la plus ancienne et la prochaine > augmente en permanence entre 2 backup/restore, à la fin de la journée > cela peut atteindre plusieurs dizaines de milliers, les perf > deviennent inacceptables. > > D'une part je en sais pas comment interpréter cela. Je dirais qu'une > transaction ne se valide pas. > D'autre part comment faire, pour que cette transaction bloquant soit > abandonnée automatiquement, qu'elle time out. > Il y a manifestement incompréhension de votre part il n'y a pas de "transaction qui ne se valide pas", ce n'est pas un probleme de "timout" si une transaction est perdue sans qu'il y est de commit ou rollback parce qu'une connexion est cassée, le mémage sera fait Là manifestement vous avec une transaction qui reste ouverte avec une connexion toujours active et d'autres transactions qui travaillent un sweep va corriger cela quand la transaction en question sera terminée vous pouvez faire un sweep manuel à vous aussi de vérifier votre application que vous n'ayez pas inutilement une transaction autre que read only read committed qui est ouverte plus que nécessaire dans la durée de vie de votre application -- Philippe Makowski http://www.ibphoenix.com Supporting users of Firebird and InterBase Firebird serveur SQL open-source en français http://firebird-fr.eu.org |
From: Richard <ri...@ro...> - 2007-10-08 07:37:30
|
On 10/6/07, Philippe Makowski <mak...@fi...> wrote: > Le 05/10/2007 11:19, Richard a dit : > > Oldest transaction 4628 > > Oldest active 4629 > > Oldest snapshot 4629 > > Next transaction 59838 > > > > Le delta entre la transaction la plus ancienne et la prochaine > > augmente en permanence entre 2 backup/restore, =E0 la fin de la journ= =E9e > > cela peut atteindre plusieurs dizaines de milliers, les perf > > deviennent inacceptables. > > > > D'une part je en sais pas comment interpr=E9ter cela. Je dirais qu'une > > transaction ne se valide pas. > > D'autre part comment faire, pour que cette transaction bloquant soit > > abandonn=E9e automatiquement, qu'elle time out. > > > Il y a manifestement incompr=E9hension de votre part > il n'y a pas de "transaction qui ne se valide pas", ce n'est pas un probl= eme de > "timout" > > si une transaction est perdue sans qu'il y est de commit ou rollback parc= e > qu'une connexion est cass=E9e, le m=E9mage sera fait > > L=E0 manifestement vous avec une transaction qui reste ouverte avec une c= onnexion > toujours active et d'autres transactions qui travaillent > > un sweep va corriger cela quand la transaction en question sera termin=E9= e > vous pouvez faire un sweep manuel > > =E0 vous aussi de v=E9rifier votre application que vous n'ayez pas inutil= ement une > transaction autre que read only read committed qui est ouverte plus que > n=E9cessaire dans la dur=E9e de vie de votre application > Merci de cet explication, je vais v=E9rifier cela au niveau de mon code Y-a-t-il un outils ou une table syst=E8me qui me permettent de connaitre la source des transactions en cours ?? RM > > -- > Philippe Makowski > http://www.ibphoenix.com > Supporting users of Firebird and InterBase > Firebird serveur SQL open-source en fran=E7ais http://firebird-fr.eu.org > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Firebird-fr-support mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firebird-fr-support > --=20 Richard Moch Traitement Statistique de l'Information 01 42 53 03 39 |
From: Philippe M. <mak...@fi...> - 2007-10-08 07:49:05
|
Le 08/10/2007 09:37, Richard a dit : > Merci de cet explication, je vais vérifier cela au niveau de mon code > Y-a-t-il un outils ou une table système qui me permettent de connaitre > la source des transactions en cours ?? > les tables de monitoring sont dans la version 2.1 (bientôt en beta2) sinon il y a des outils comme IBTransactionMonitor (http://ibphoenix.com/main.nfs?a=ibphoenix&s=1191829566:176473&page=ibp_ibtm) ou encore cet utilitaire fait par Henri : UIB SQL Monitor http://www.progdigy.com/modules.php?name=News&file=article&sid=7 - Philippe Makowski http://www.ibphoenix.com Supporting users of Firebird and InterBase Firebird serveur SQL open-source en français http://firebird-fr.eu.org |
From: Richard <ri...@ro...> - 2007-10-08 10:16:43
|
> les tables de monitoring sont dans la version 2.1 (bient=F4t en beta2) > sinon il y a des outils comme IBTransactionMonitor > (http://ibphoenix.com/main.nfs?a=3Dibphoenix&s=3D1191829566:176473&page= =3Dibp_ibtm) > ou encore cet utilitaire fait par Henri : UIB SQL Monitor > http://www.progdigy.com/modules.php?name=3DNews&file=3Darticle&sid=3D7 OK, j'ai v=E9rifi=E9 toute mes transactions, certaines =E9taient en snapsho= t. Sur vos conseils, j'ai tout passer en Read Commiter (read_committed, rec_version, nowait), pour voir: pas d'am=E9lioration S'il reste une transaction d=E9marr=E9 sur une connexion active, je ne sais pas d'o=F9 elle vient. Auriez vous d'autres piste ? Concernant les outils de monitor, celui de Herv=E9 n'est pas adapt=E9 =E0 mon probl=E8me, et je ne parvient pas =E0 faire fonctionner IBTransactionMonitor (je le configure, il se connecte =E0 la base, mais le fichier de log n'est jamais g=E9n=E9r=E9) RM --=20 Richard Moch Traitement Statistique de l'Information 01 42 53 03 39 |
From: Philippe M. <mak...@fi...> - 2007-10-08 10:25:37
|
Le 08/10/2007 12:16, Richard a dit : >> les tables de monitoring sont dans la version 2.1 (bientôt en beta2) >> sinon il y a des outils comme IBTransactionMonitor >> (http://ibphoenix.com/main.nfs?a=ibphoenix&s=1191829566:176473&page=ibp_ibtm) >> ou encore cet utilitaire fait par Henri : UIB SQL Monitor >> http://www.progdigy.com/modules.php?name=News&file=article&sid=7 > > OK, j'ai vérifié toute mes transactions, certaines étaient en snapshot. > Sur vos conseils, j'ai tout passer en Read Commiter (read_committed, > rec_version, nowait), pour voir: pas d'amélioration > S'il reste une transaction démarré sur une connexion active, je ne > sais pas d'où elle vient. > pardon ? je n'ai jamais conseillé cela j'ai simplement dit si vous avez besoin dans votre application d'une transaction pour afficher par exemple une table de monitorring durant un long moement, alors pour ce besoin particulier, utilisez une transaction READ ONLY, READ COMMITTED avec des commit retains pour ne pas bloquer le processus d'évolution des transactions > Auriez vous d'autres piste ? > lire votre code ou faire un test avec Firebird 2.1 et les tables système de monitoring Parler comme ça en général sans connaitre l'architecture de votre application, le langage et le pilote utilisé est difficile N'oubliez pas qu'un SELECT se fait dans le cadre d'une transaction aussi |
From: Michel2 <mic...@fr...> - 2007-10-08 10:48:39
|
Bonjour, Je pense qu'il y a quelque part une erreur d'adressage.... J'ai reçu plusieurs de vos mèls à l'adresse : mic...@fr.... Sans gravité mais le véritable destinataire attend peut-être. Salutations ----- Original Message ----- From: "Richard" <ri...@ro...> To: "support en français sur Firebird" <fir...@li...> Sent: Monday, October 08, 2007 12:16 PM Subject: Re: [Firebird-fr-support] transaction bloquée > les tables de monitoring sont dans la version 2.1 (bientôt en beta2) > sinon il y a des outils comme IBTransactionMonitor > (http://ibphoenix.com/main.nfs?a=ibphoenix&s=1191829566:176473&page=ibp_ibtm) > ou encore cet utilitaire fait par Henri : UIB SQL Monitor > http://www.progdigy.com/modules.php?name=News&file=article&sid=7 OK, j'ai vérifié toute mes transactions, certaines étaient en snapshot. Sur vos conseils, j'ai tout passer en Read Commiter (read_committed, rec_version, nowait), pour voir: pas d'amélioration S'il reste une transaction démarré sur une connexion active, je ne sais pas d'où elle vient. Auriez vous d'autres piste ? Concernant les outils de monitor, celui de Hervé n'est pas adapté à mon problème, et je ne parvient pas à faire fonctionner IBTransactionMonitor (je le configure, il se connecte à la base, mais le fichier de log n'est jamais généré) RM -- Richard Moch Traitement Statistique de l'Information 01 42 53 03 39 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Firebird-fr-support mailing list Fir...@li... https://lists.sourceforge.net/lists/listinfo/firebird-fr-support |
From: Philippe M. <mak...@fi...> - 2007-10-08 11:04:36
|
Bonjour, Le 08/10/2007 12:50, Michel2 a dit : > Je pense qu'il y a quelque part une erreur d'adressage.... > J'ai reçu plusieurs de vos mèls à l'adresse : mic...@fr.... > > Sans gravité mais le véritable destinataire attend peut-être. > non, c'est juste que vous êtes inscrits à la liste de discussion suivante : Fir...@li... https://lists.sourceforge.net/lists/listinfo/firebird-fr-support |