Si l'article de Ron Talmage explique comment remonter à la table et l'index
incriminé lors d'un deadlock sur une ressource de type KEY, je ne vois pas
comment faire dans le cas d'un deadlock sur deux ressources de type PAG.
Mon deadlock est du type suivant :
SPID 56 a obtenu un verrou IX sur PAG 7:1:19150 pour INSERT
SPID 91 faisait un request pour un verrou S sur PAG 7:1:19150
SPID 91 a obtenu un verrou S sur PAG 7:1:191829 pour un execute
SPID 56 attent un verrou IX sur PAG 7:1:191829
Je n'ai malheureusement pas la trace des SPID ci-dessus. Puis-je malgré tout
identifier la table et/ou l'index à mettre en cause grace aux pages. Que
faire du page_no, file_no, row_no?
Merci de votre aide.
Contexte SQL Server :
Il s'agit d'une application initialement sous Oracle, que nous faisons
fonctionner sous SQL Server 2000 SP4.
Nous avons une dizaine de deadlocks par semaine.
Nous utilisons le mode READ_COMMITED et IMPLICIT_TRANSACTION OFF
La durée des transactions a été minimisée au maximum.
La justesse des informations lues est capitale pour nous (milieu médical),
aussi sommes-nous rétiçant à faire usage des hints de type WITH NOLOCK.
Présence de nombreuses tâches de fonds effectuant régulièrement des selects,
et quelques update.
SQL Profiler est paramétré sur les évènements conseillés par Mr Talmage,
sans les [RPC/SP/SQLBatch/Stmt]Starting (seulement les 'Completed') pour
limiter le nombre de lignes de trace. Ceci génère 800 000 lignes de
l'heure...
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
Fred BROUARD
Rémy Vassal a écrit :
Bonjour,
Si l'article de Ron Talmage explique comment remonter à la table et l'index incriminé lors d'un deadlock sur une ressource de type KEY, je ne vois pas comment faire dans le cas d'un deadlock sur deux ressources de type PAG.
Mon deadlock est du type suivant :
SPID 56 a obtenu un verrou IX sur PAG 7:1:19150 pour INSERT SPID 91 faisait un request pour un verrou S sur PAG 7:1:19150 SPID 91 a obtenu un verrou S sur PAG 7:1:191829 pour un execute SPID 56 attent un verrou IX sur PAG 7:1:191829
Je n'ai malheureusement pas la trace des SPID ci-dessus. Puis-je malgré tout identifier la table et/ou l'index à mettre en cause grace aux pages. Que faire du page_no, file_no, row_no?
Merci de votre aide.
Contexte SQL Server : Il s'agit d'une application initialement sous Oracle, que nous faisons fonctionner sous SQL Server 2000 SP4. Nous avons une dizaine de deadlocks par semaine. Nous utilisons le mode READ_COMMITED et IMPLICIT_TRANSACTION OFF
pourquoi êtes vous en IMPLICIT_TRANSACTION OFF ??? C'est à mon avis la raison principale des nompbreux deadlocks, car chaque connexion démarre une transaction ce qui n'est pas nécessaire dans bien des cas.
La durée des transactions a été minimisée au maximum. La justesse des informations lues est capitale pour nous (milieu médical),
comme pour toutes les applications qui utilisent des SGBDR !
aussi sommes-nous rétiçant à faire usage des hints de type WITH NOLOCK.
cela dépend de l'info que vous avez besoin... par exemple pour éditer un graphique à partir de statistiques aucune importance. En revanche pour une données comptable c'est important ! Il faut relativiser....
Présence de nombreuses tâches de fonds effectuant régulièrement des selects, et quelques update. SQL Profiler est paramétré sur les évènements conseillés par Mr Talmage, sans les [RPC/SP/SQLBatch/Stmt]Starting (seulement les 'Completed') pour limiter le nombre de lignes de trace. Ceci génère 800 000 lignes de l'heure...
Si vous êtes en version 2005, jouez sur les niveau d'isolation SNAPSHOT, vous obtiendrez à peu près le même comportement qu'Oracle.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Rémy Vassal a écrit :
Bonjour,
Si l'article de Ron Talmage explique comment remonter à la table et l'index
incriminé lors d'un deadlock sur une ressource de type KEY, je ne vois pas
comment faire dans le cas d'un deadlock sur deux ressources de type PAG.
Mon deadlock est du type suivant :
SPID 56 a obtenu un verrou IX sur PAG 7:1:19150 pour INSERT
SPID 91 faisait un request pour un verrou S sur PAG 7:1:19150
SPID 91 a obtenu un verrou S sur PAG 7:1:191829 pour un execute
SPID 56 attent un verrou IX sur PAG 7:1:191829
Je n'ai malheureusement pas la trace des SPID ci-dessus. Puis-je malgré tout
identifier la table et/ou l'index à mettre en cause grace aux pages. Que
faire du page_no, file_no, row_no?
Merci de votre aide.
Contexte SQL Server :
Il s'agit d'une application initialement sous Oracle, que nous faisons
fonctionner sous SQL Server 2000 SP4.
Nous avons une dizaine de deadlocks par semaine.
Nous utilisons le mode READ_COMMITED et IMPLICIT_TRANSACTION OFF
pourquoi êtes vous en IMPLICIT_TRANSACTION OFF ???
C'est à mon avis la raison principale des nompbreux deadlocks, car
chaque connexion démarre une transaction ce qui n'est pas nécessaire
dans bien des cas.
La durée des transactions a été minimisée au maximum.
La justesse des informations lues est capitale pour nous (milieu médical),
comme pour toutes les applications qui utilisent des SGBDR !
aussi sommes-nous rétiçant à faire usage des hints de type WITH NOLOCK.
cela dépend de l'info que vous avez besoin... par exemple pour éditer un
graphique à partir de statistiques aucune importance. En revanche pour
une données comptable c'est important !
Il faut relativiser....
Présence de nombreuses tâches de fonds effectuant régulièrement des selects,
et quelques update.
SQL Profiler est paramétré sur les évènements conseillés par Mr Talmage,
sans les [RPC/SP/SQLBatch/Stmt]Starting (seulement les 'Completed') pour
limiter le nombre de lignes de trace. Ceci génère 800 000 lignes de
l'heure...
Si vous êtes en version 2005, jouez sur les niveau d'isolation SNAPSHOT,
vous obtiendrez à peu près le même comportement qu'Oracle.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Si l'article de Ron Talmage explique comment remonter à la table et l'index incriminé lors d'un deadlock sur une ressource de type KEY, je ne vois pas comment faire dans le cas d'un deadlock sur deux ressources de type PAG.
Mon deadlock est du type suivant :
SPID 56 a obtenu un verrou IX sur PAG 7:1:19150 pour INSERT SPID 91 faisait un request pour un verrou S sur PAG 7:1:19150 SPID 91 a obtenu un verrou S sur PAG 7:1:191829 pour un execute SPID 56 attent un verrou IX sur PAG 7:1:191829
Je n'ai malheureusement pas la trace des SPID ci-dessus. Puis-je malgré tout identifier la table et/ou l'index à mettre en cause grace aux pages. Que faire du page_no, file_no, row_no?
Merci de votre aide.
Contexte SQL Server : Il s'agit d'une application initialement sous Oracle, que nous faisons fonctionner sous SQL Server 2000 SP4. Nous avons une dizaine de deadlocks par semaine. Nous utilisons le mode READ_COMMITED et IMPLICIT_TRANSACTION OFF
pourquoi êtes vous en IMPLICIT_TRANSACTION OFF ??? C'est à mon avis la raison principale des nompbreux deadlocks, car chaque connexion démarre une transaction ce qui n'est pas nécessaire dans bien des cas.
La durée des transactions a été minimisée au maximum. La justesse des informations lues est capitale pour nous (milieu médical),
comme pour toutes les applications qui utilisent des SGBDR !
aussi sommes-nous rétiçant à faire usage des hints de type WITH NOLOCK.
cela dépend de l'info que vous avez besoin... par exemple pour éditer un graphique à partir de statistiques aucune importance. En revanche pour une données comptable c'est important ! Il faut relativiser....
Présence de nombreuses tâches de fonds effectuant régulièrement des selects, et quelques update. SQL Profiler est paramétré sur les évènements conseillés par Mr Talmage, sans les [RPC/SP/SQLBatch/Stmt]Starting (seulement les 'Completed') pour limiter le nombre de lignes de trace. Ceci génère 800 000 lignes de l'heure...
Si vous êtes en version 2005, jouez sur les niveau d'isolation SNAPSHOT, vous obtiendrez à peu près le même comportement qu'Oracle.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Med Bouchenafa
http://support.microsoft.com/kb/832524/
-- Bien cordialement Med Bouchenafa
"Rémy Vassal" wrote in message news:
Bonjour,
Si l'article de Ron Talmage explique comment remonter à la table et l'index incriminé lors d'un deadlock sur une ressource de type KEY, je ne vois pas comment faire dans le cas d'un deadlock sur deux ressources de type PAG.
Mon deadlock est du type suivant :
SPID 56 a obtenu un verrou IX sur PAG 7:1:19150 pour INSERT SPID 91 faisait un request pour un verrou S sur PAG 7:1:19150 SPID 91 a obtenu un verrou S sur PAG 7:1:191829 pour un execute SPID 56 attent un verrou IX sur PAG 7:1:191829
Je n'ai malheureusement pas la trace des SPID ci-dessus. Puis-je malgré tout identifier la table et/ou l'index à mettre en cause grace aux pages. Que faire du page_no, file_no, row_no?
Merci de votre aide.
Contexte SQL Server : Il s'agit d'une application initialement sous Oracle, que nous faisons fonctionner sous SQL Server 2000 SP4. Nous avons une dizaine de deadlocks par semaine. Nous utilisons le mode READ_COMMITED et IMPLICIT_TRANSACTION OFF La durée des transactions a été minimisée au maximum. La justesse des informations lues est capitale pour nous (milieu médical), aussi sommes-nous rétiçant à faire usage des hints de type WITH NOLOCK. Présence de nombreuses tâches de fonds effectuant régulièrement des selects, et quelques update. SQL Profiler est paramétré sur les évènements conseillés par Mr Talmage, sans les [RPC/SP/SQLBatch/Stmt]Starting (seulement les 'Completed') pour limiter le nombre de lignes de trace. Ceci génère 800 000 lignes de l'heure...
http://support.microsoft.com/kb/832524/
--
Bien cordialement
Med Bouchenafa
"Rémy Vassal" <remy.vassal@club-internet.fr> wrote in message
news:uILrCGCUHHA.996@TK2MSFTNGP02.phx.gbl...
Bonjour,
Si l'article de Ron Talmage explique comment remonter à la table et
l'index incriminé lors d'un deadlock sur une ressource de type KEY, je ne
vois pas comment faire dans le cas d'un deadlock sur deux ressources de
type PAG.
Mon deadlock est du type suivant :
SPID 56 a obtenu un verrou IX sur PAG 7:1:19150 pour INSERT
SPID 91 faisait un request pour un verrou S sur PAG 7:1:19150
SPID 91 a obtenu un verrou S sur PAG 7:1:191829 pour un execute
SPID 56 attent un verrou IX sur PAG 7:1:191829
Je n'ai malheureusement pas la trace des SPID ci-dessus. Puis-je malgré
tout identifier la table et/ou l'index à mettre en cause grace aux pages.
Que faire du page_no, file_no, row_no?
Merci de votre aide.
Contexte SQL Server :
Il s'agit d'une application initialement sous Oracle, que nous faisons
fonctionner sous SQL Server 2000 SP4.
Nous avons une dizaine de deadlocks par semaine.
Nous utilisons le mode READ_COMMITED et IMPLICIT_TRANSACTION OFF
La durée des transactions a été minimisée au maximum.
La justesse des informations lues est capitale pour nous (milieu médical),
aussi sommes-nous rétiçant à faire usage des hints de type WITH NOLOCK.
Présence de nombreuses tâches de fonds effectuant régulièrement des
selects, et quelques update.
SQL Profiler est paramétré sur les évènements conseillés par Mr Talmage,
sans les [RPC/SP/SQLBatch/Stmt]Starting (seulement les 'Completed') pour
limiter le nombre de lignes de trace. Ceci génère 800 000 lignes de
l'heure...
Si l'article de Ron Talmage explique comment remonter à la table et l'index incriminé lors d'un deadlock sur une ressource de type KEY, je ne vois pas comment faire dans le cas d'un deadlock sur deux ressources de type PAG.
Mon deadlock est du type suivant :
SPID 56 a obtenu un verrou IX sur PAG 7:1:19150 pour INSERT SPID 91 faisait un request pour un verrou S sur PAG 7:1:19150 SPID 91 a obtenu un verrou S sur PAG 7:1:191829 pour un execute SPID 56 attent un verrou IX sur PAG 7:1:191829
Je n'ai malheureusement pas la trace des SPID ci-dessus. Puis-je malgré tout identifier la table et/ou l'index à mettre en cause grace aux pages. Que faire du page_no, file_no, row_no?
Merci de votre aide.
Contexte SQL Server : Il s'agit d'une application initialement sous Oracle, que nous faisons fonctionner sous SQL Server 2000 SP4. Nous avons une dizaine de deadlocks par semaine. Nous utilisons le mode READ_COMMITED et IMPLICIT_TRANSACTION OFF La durée des transactions a été minimisée au maximum. La justesse des informations lues est capitale pour nous (milieu médical), aussi sommes-nous rétiçant à faire usage des hints de type WITH NOLOCK. Présence de nombreuses tâches de fonds effectuant régulièrement des selects, et quelques update. SQL Profiler est paramétré sur les évènements conseillés par Mr Talmage, sans les [RPC/SP/SQLBatch/Stmt]Starting (seulement les 'Completed') pour limiter le nombre de lignes de trace. Ceci génère 800 000 lignes de l'heure...
