Bonjour à tous,
Je suis actuellement confronté à un problème de transaction maintenue
ouverte par une session qui n'effectue plus aucun traitement sous SQL Server
2000 (8.00.2040). Ce qui m'embête est que le type de transaction n'est ni
transaction utilisateur "classique", ni transaction implicite comme pourrait
l'ouvrir un driver jdbc par exemple.
La transaction est identifiée comme une transaction DML (c'est ce que me
retourne DBCC OPENTRAN), et puisque je sais que les développeurs de
l'application n'ont jamais recours à des transactions nommées, je pars du
principe qu'il s'agit effectivement d'une transaction DML.
J'ai essayé de reproduire une situation dans laquelle une telle transaction
ne serait pas extrêment furtive, mais en vain ( même en jouant sur
l'Isolation Level par exemple)
Aucune info dans la KB Microsoft sur un bug à ce sujet.
L'un d'entre vous a-t-il une idée sur le sujet ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Christian Robert
Pour moi l'essentiel serait de retrouver qui a ouvert cette transaction donc rechercher l'Id de Session en question, vérifier la ou les dernières commandes passées par celle-ci...
Au besoin lancer SQL Profiler (Genérateur de Profil) pour obtenir une trace intégrale de cette application pour savoir réellement ce qui se passe et pourquoi la trasaction ne fait pas de COMMIT et où elle devrait le faire...
Cordialement
------------------------------ Christian Robert Winwise MCT - MCDBA - MCSD.Net
"BVesan" a écrit :
Bonjour à tous, Je suis actuellement confronté à un problème de transaction maintenue ouverte par une session qui n'effectue plus aucun traitement sous SQL Server 2000 (8.00.2040). Ce qui m'embête est que le type de transaction n'est ni transaction utilisateur "classique", ni transaction implicite comme pourrait l'ouvrir un driver jdbc par exemple. La transaction est identifiée comme une transaction DML (c'est ce que me retourne DBCC OPENTRAN), et puisque je sais que les développeurs de l'application n'ont jamais recours à des transactions nommées, je pars du principe qu'il s'agit effectivement d'une transaction DML.
J'ai essayé de reproduire une situation dans laquelle une telle transaction ne serait pas extrêment furtive, mais en vain ( même en jouant sur l'Isolation Level par exemple) Aucune info dans la KB Microsoft sur un bug à ce sujet. L'un d'entre vous a-t-il une idée sur le sujet ?
Benjamin.
Pour moi l'essentiel serait de retrouver qui a ouvert cette transaction donc
rechercher l'Id de Session en question, vérifier la ou les dernières
commandes passées par celle-ci...
Au besoin lancer SQL Profiler (Genérateur de Profil) pour obtenir une trace
intégrale de cette application pour savoir réellement ce qui se passe et
pourquoi la trasaction ne fait pas de COMMIT et où elle devrait le faire...
Cordialement
------------------------------
Christian Robert
Winwise
MCT - MCDBA - MCSD.Net
"BVesan" a écrit :
Bonjour à tous,
Je suis actuellement confronté à un problème de transaction maintenue
ouverte par une session qui n'effectue plus aucun traitement sous SQL Server
2000 (8.00.2040). Ce qui m'embête est que le type de transaction n'est ni
transaction utilisateur "classique", ni transaction implicite comme pourrait
l'ouvrir un driver jdbc par exemple.
La transaction est identifiée comme une transaction DML (c'est ce que me
retourne DBCC OPENTRAN), et puisque je sais que les développeurs de
l'application n'ont jamais recours à des transactions nommées, je pars du
principe qu'il s'agit effectivement d'une transaction DML.
J'ai essayé de reproduire une situation dans laquelle une telle transaction
ne serait pas extrêment furtive, mais en vain ( même en jouant sur
l'Isolation Level par exemple)
Aucune info dans la KB Microsoft sur un bug à ce sujet.
L'un d'entre vous a-t-il une idée sur le sujet ?
Pour moi l'essentiel serait de retrouver qui a ouvert cette transaction donc rechercher l'Id de Session en question, vérifier la ou les dernières commandes passées par celle-ci...
Au besoin lancer SQL Profiler (Genérateur de Profil) pour obtenir une trace intégrale de cette application pour savoir réellement ce qui se passe et pourquoi la trasaction ne fait pas de COMMIT et où elle devrait le faire...
Cordialement
------------------------------ Christian Robert Winwise MCT - MCDBA - MCSD.Net
"BVesan" a écrit :
Bonjour à tous, Je suis actuellement confronté à un problème de transaction maintenue ouverte par une session qui n'effectue plus aucun traitement sous SQL Server 2000 (8.00.2040). Ce qui m'embête est que le type de transaction n'est ni transaction utilisateur "classique", ni transaction implicite comme pourrait l'ouvrir un driver jdbc par exemple. La transaction est identifiée comme une transaction DML (c'est ce que me retourne DBCC OPENTRAN), et puisque je sais que les développeurs de l'application n'ont jamais recours à des transactions nommées, je pars du principe qu'il s'agit effectivement d'une transaction DML.
J'ai essayé de reproduire une situation dans laquelle une telle transaction ne serait pas extrêment furtive, mais en vain ( même en jouant sur l'Isolation Level par exemple) Aucune info dans la KB Microsoft sur un bug à ce sujet. L'un d'entre vous a-t-il une idée sur le sujet ?
Benjamin.
BVesan
J'ai tracé la session et vérifié dans le code de la dernière commande passée (une procédure stockée). rien de particulier. La trace fait bien entendu remonter des évenements SQLTransaction nommées DML à chaque modification de données, mais je n'ai pas réussi à identifier un quelconque comportement anormal (à chaque création de transaction DML, je trouve la fermeture associée)...
J'ai tracé la session et vérifié dans le code de la dernière commande passée
(une procédure stockée). rien de particulier.
La trace fait bien entendu remonter des évenements SQLTransaction nommées
DML à chaque modification de données, mais je n'ai pas réussi à identifier un
quelconque comportement anormal (à chaque création de transaction DML, je
trouve la fermeture associée)...
J'ai tracé la session et vérifié dans le code de la dernière commande passée (une procédure stockée). rien de particulier. La trace fait bien entendu remonter des évenements SQLTransaction nommées DML à chaque modification de données, mais je n'ai pas réussi à identifier un quelconque comportement anormal (à chaque création de transaction DML, je trouve la fermeture associée)...
Christian Robert
Est ce que le nombre de transactions ouvertes augmente ou reste stable ? (compteur du nombre de transaction active ouverte dans Dans l'outils de perfomrnace de Windows) Est ce que des verrous sont laissés en place sur des objets (tables, ...) ?
Est ce qu'une commande SET IMPLICIT_TRANSACTION ON est passé ?
En fait est ce gênant ou bloquant ? Est ce que la situation s'aggrave ?
------------------------------ Christian Robert Winwise MCT - MCDBA - MCSD.Net
"BVesan" a écrit :
J'ai tracé la session et vérifié dans le code de la dernière commande passée (une procédure stockée). rien de particulier. La trace fait bien entendu remonter des évenements SQLTransaction nommées DML à chaque modification de données, mais je n'ai pas réussi à identifier un quelconque comportement anormal (à chaque création de transaction DML, je trouve la fermeture associée)...
Est ce que le nombre de transactions ouvertes augmente ou reste stable ?
(compteur du nombre de transaction active ouverte dans Dans l'outils de
perfomrnace de Windows)
Est ce que des verrous sont laissés en place sur des objets (tables, ...) ?
Est ce qu'une commande SET IMPLICIT_TRANSACTION ON est passé ?
En fait est ce gênant ou bloquant ? Est ce que la situation s'aggrave ?
------------------------------
Christian Robert
Winwise
MCT - MCDBA - MCSD.Net
"BVesan" a écrit :
J'ai tracé la session et vérifié dans le code de la dernière commande passée
(une procédure stockée). rien de particulier.
La trace fait bien entendu remonter des évenements SQLTransaction nommées
DML à chaque modification de données, mais je n'ai pas réussi à identifier un
quelconque comportement anormal (à chaque création de transaction DML, je
trouve la fermeture associée)...
Est ce que le nombre de transactions ouvertes augmente ou reste stable ? (compteur du nombre de transaction active ouverte dans Dans l'outils de perfomrnace de Windows) Est ce que des verrous sont laissés en place sur des objets (tables, ...) ?
Est ce qu'une commande SET IMPLICIT_TRANSACTION ON est passé ?
En fait est ce gênant ou bloquant ? Est ce que la situation s'aggrave ?
------------------------------ Christian Robert Winwise MCT - MCDBA - MCSD.Net
"BVesan" a écrit :
J'ai tracé la session et vérifié dans le code de la dernière commande passée (une procédure stockée). rien de particulier. La trace fait bien entendu remonter des évenements SQLTransaction nommées DML à chaque modification de données, mais je n'ai pas réussi à identifier un quelconque comportement anormal (à chaque création de transaction DML, je trouve la fermeture associée)...
Michel PRIORI
C'est pas bien, mais ça arrive ... beaucoup moins en version 2000 que 7 tout de même. Logiquement SQL devrait avoir un client actif pour chaque transaction en cours. Il arrive que des transactions soient ouvertes et que le client ne soit plus là pour terminer la transaction (par commit ou rollback) sans que SQL s'en apperçoive. Il faut alors tuer la transaction, ce qui fera un rollback, car on ne sais pas a priori si le dernier ordre est bien arrivé.
De mémoire, il existe une commande BDCC_opentran (pas sûr de l'orthographe) qui liste la transaction la plus ancienne. Ordre à executer règulièrement.
Cordialement
"Christian Robert" wrote:
Est ce que le nombre de transactions ouvertes augmente ou reste stable ? (compteur du nombre de transaction active ouverte dans Dans l'outils de perfomrnace de Windows) Est ce que des verrous sont laissés en place sur des objets (tables, ...) ?
Est ce qu'une commande SET IMPLICIT_TRANSACTION ON est passé ?
En fait est ce gênant ou bloquant ? Est ce que la situation s'aggrave ?
------------------------------ Christian Robert Winwise MCT - MCDBA - MCSD.Net
"BVesan" a écrit :
> J'ai tracé la session et vérifié dans le code de la dernière commande passée > (une procédure stockée). rien de particulier. > La trace fait bien entendu remonter des évenements SQLTransaction nommées > DML à chaque modification de données, mais je n'ai pas réussi à identifier un > quelconque comportement anormal (à chaque création de transaction DML, je > trouve la fermeture associée)...
C'est pas bien, mais ça arrive ... beaucoup moins en version 2000 que 7 tout
de même.
Logiquement SQL devrait avoir un client actif pour chaque transaction en
cours.
Il arrive que des transactions soient ouvertes et que le client ne soit plus
là pour terminer la transaction (par commit ou rollback) sans que SQL s'en
apperçoive.
Il faut alors tuer la transaction, ce qui fera un rollback, car on ne sais
pas a priori si le dernier ordre est bien arrivé.
De mémoire, il existe une commande BDCC_opentran (pas sûr de l'orthographe)
qui liste la transaction la plus ancienne. Ordre à executer règulièrement.
Cordialement
"Christian Robert" wrote:
Est ce que le nombre de transactions ouvertes augmente ou reste stable ?
(compteur du nombre de transaction active ouverte dans Dans l'outils de
perfomrnace de Windows)
Est ce que des verrous sont laissés en place sur des objets (tables, ...) ?
Est ce qu'une commande SET IMPLICIT_TRANSACTION ON est passé ?
En fait est ce gênant ou bloquant ? Est ce que la situation s'aggrave ?
------------------------------
Christian Robert
Winwise
MCT - MCDBA - MCSD.Net
"BVesan" a écrit :
> J'ai tracé la session et vérifié dans le code de la dernière commande passée
> (une procédure stockée). rien de particulier.
> La trace fait bien entendu remonter des évenements SQLTransaction nommées
> DML à chaque modification de données, mais je n'ai pas réussi à identifier un
> quelconque comportement anormal (à chaque création de transaction DML, je
> trouve la fermeture associée)...
C'est pas bien, mais ça arrive ... beaucoup moins en version 2000 que 7 tout de même. Logiquement SQL devrait avoir un client actif pour chaque transaction en cours. Il arrive que des transactions soient ouvertes et que le client ne soit plus là pour terminer la transaction (par commit ou rollback) sans que SQL s'en apperçoive. Il faut alors tuer la transaction, ce qui fera un rollback, car on ne sais pas a priori si le dernier ordre est bien arrivé.
De mémoire, il existe une commande BDCC_opentran (pas sûr de l'orthographe) qui liste la transaction la plus ancienne. Ordre à executer règulièrement.
Cordialement
"Christian Robert" wrote:
Est ce que le nombre de transactions ouvertes augmente ou reste stable ? (compteur du nombre de transaction active ouverte dans Dans l'outils de perfomrnace de Windows) Est ce que des verrous sont laissés en place sur des objets (tables, ...) ?
Est ce qu'une commande SET IMPLICIT_TRANSACTION ON est passé ?
En fait est ce gênant ou bloquant ? Est ce que la situation s'aggrave ?
------------------------------ Christian Robert Winwise MCT - MCDBA - MCSD.Net
"BVesan" a écrit :
> J'ai tracé la session et vérifié dans le code de la dernière commande passée > (une procédure stockée). rien de particulier. > La trace fait bien entendu remonter des évenements SQLTransaction nommées > DML à chaque modification de données, mais je n'ai pas réussi à identifier un > quelconque comportement anormal (à chaque création de transaction DML, je > trouve la fermeture associée)...
