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
Rudi Bruchez
Brigitte a écrit:
Bonjour,
Nous avons de problèmes de locks sur une table. Comment tracer cela? Comment régler cela?
Bonjour,
le sujet est large. En détaillant un peu ton problème, nous pourrons donner des réponses plus spécifiques. Tu peux commencer avec : - sp_lock pour voir les verrous tenus à un instant T - qqch comme SELECT * FROM master.dbo.sysprocesses WHERE blocked > 0 (sur sql 2000) pour les processus qui attendent la libération de verrous, - WITH (READUNCOMMITTED) ou SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED pour éviter des locks de lecture dans des SELECT - il y a ici (pub) http://www.babaluga.org/doku.php/sql_server/administration/index un code maison pour tracer les situations de blocage
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Brigitte a écrit:
Bonjour,
Nous avons de problèmes de locks sur une table.
Comment tracer cela?
Comment régler cela?
Bonjour,
le sujet est large. En détaillant un peu ton problème, nous pourrons donner
des réponses plus spécifiques.
Tu peux commencer avec :
- sp_lock pour voir les verrous tenus à un instant T
- qqch comme SELECT * FROM master.dbo.sysprocesses WHERE blocked > 0 (sur
sql 2000) pour les processus qui attendent la libération de verrous,
- WITH (READUNCOMMITTED) ou SET TRANSACTION ISOLATION LEVEL READ
UNCOMMITTED pour éviter des locks de lecture dans des SELECT
- il y a ici (pub)
http://www.babaluga.org/doku.php/sql_server/administration/index un code
maison pour tracer les situations de blocage
Nous avons de problèmes de locks sur une table. Comment tracer cela? Comment régler cela?
Bonjour,
le sujet est large. En détaillant un peu ton problème, nous pourrons donner des réponses plus spécifiques. Tu peux commencer avec : - sp_lock pour voir les verrous tenus à un instant T - qqch comme SELECT * FROM master.dbo.sysprocesses WHERE blocked > 0 (sur sql 2000) pour les processus qui attendent la libération de verrous, - WITH (READUNCOMMITTED) ou SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED pour éviter des locks de lecture dans des SELECT - il y a ici (pub) http://www.babaluga.org/doku.php/sql_server/administration/index un code maison pour tracer les situations de blocage
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Christian Robert
Pour tracer les locks à mon sens le plus simple est passer par le Profiler SQL, cela fait parti des évennements qu'il sait tracer.
sp_lock est bien, mais présente une vision instantané de la chose et donc pas évident de se connecter au serveur et de tomber pile sur le lock.
Les compteurs de performance donnent aussi une assez bonne idée, tel que : o Average Wait Time (ms) o Lock Timeouts/sec o Number of Deadlocks/sec Ils permettent surtout de connaître la fréquence du problème.
Par contre je suis absolument contre l'usage des WITH(NOLOCK) et plus généralement de l'utilisation du niveau READ UNCOMMITED. EN effet ce niveau d'isolation provoque un risque fort d'erreur dans la base, étant donné qu'il permet la lecture de valeurs temporaires ou de travaille, ou de données erronnée qui vont être passées en ROLLBACK !
De plus en général, leur usage n'est pas réfléchis et on les retrouve dans quasiement toutes les requêtes par la suite.
Le plus simple pour éviter les problèmes de lock : - Limitez la durée des transactions, et démarrer votre transaction le plus tard possible (juste avant les commandes de mise à jour) et terminez là le plus tôt possible. - Quand cela est possible fragmentez les mises à jour par paquet (par bloc d'enregistrement, plutot que sur une table complète) - Limitez l'usage des triggers aux tables les moins fréquement mises à jours.
SQL Server 2005 propose un mode Snapshot qui solutionne aussi ce genre de problèmes.
-- Cordialement
Christian Robert Consultant - Formateur chez Winwise MCT - MCDBA - MCSD MCTS & MCITP SQL Server 2005
"Rudi Bruchez" <"rudi#nospam#[at]babaluga" a écrit :
Brigitte a écrit:
> Bonjour, > > Nous avons de problèmes de locks sur une table. > Comment tracer cela? > Comment régler cela? >
Bonjour,
le sujet est large. En détaillant un peu ton problème, nous pourrons donner des réponses plus spécifiques. Tu peux commencer avec : - sp_lock pour voir les verrous tenus à un instant T - qqch comme SELECT * FROM master.dbo.sysprocesses WHERE blocked > 0 (sur sql 2000) pour les processus qui attendent la libération de verrous, - WITH (READUNCOMMITTED) ou SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED pour éviter des locks de lecture dans des SELECT - il y a ici (pub) http://www.babaluga.org/doku.php/sql_server/administration/index un code maison pour tracer les situations de blocage
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Pour tracer les locks à mon sens le plus simple est passer par le Profiler
SQL, cela fait parti des évennements qu'il sait tracer.
sp_lock est bien, mais présente une vision instantané de la chose et donc
pas évident de se connecter au serveur et de tomber pile sur le lock.
Les compteurs de performance donnent aussi une assez bonne idée, tel que :
o Average Wait Time (ms)
o Lock Timeouts/sec
o Number of Deadlocks/sec
Ils permettent surtout de connaître la fréquence du problème.
Par contre je suis absolument contre l'usage des WITH(NOLOCK) et plus
généralement de l'utilisation du niveau READ UNCOMMITED.
EN effet ce niveau d'isolation provoque un risque fort d'erreur dans la
base, étant donné qu'il permet la lecture de valeurs temporaires ou de
travaille, ou de données erronnée qui vont être passées en ROLLBACK !
De plus en général, leur usage n'est pas réfléchis et on les retrouve dans
quasiement toutes les requêtes par la suite.
Le plus simple pour éviter les problèmes de lock :
- Limitez la durée des transactions, et démarrer votre transaction le plus
tard possible (juste avant les commandes de mise à jour) et terminez là le
plus tôt possible.
- Quand cela est possible fragmentez les mises à jour par paquet (par bloc
d'enregistrement, plutot que sur une table complète)
- Limitez l'usage des triggers aux tables les moins fréquement mises à jours.
SQL Server 2005 propose un mode Snapshot qui solutionne aussi ce genre de
problèmes.
--
Cordialement
Christian Robert
Consultant - Formateur chez Winwise
MCT - MCDBA - MCSD
MCTS & MCITP SQL Server 2005
"Rudi Bruchez" <"rudi#nospam#[at]babaluga" a écrit :
Brigitte a écrit:
> Bonjour,
>
> Nous avons de problèmes de locks sur une table.
> Comment tracer cela?
> Comment régler cela?
>
Bonjour,
le sujet est large. En détaillant un peu ton problème, nous pourrons donner
des réponses plus spécifiques.
Tu peux commencer avec :
- sp_lock pour voir les verrous tenus à un instant T
- qqch comme SELECT * FROM master.dbo.sysprocesses WHERE blocked > 0 (sur
sql 2000) pour les processus qui attendent la libération de verrous,
- WITH (READUNCOMMITTED) ou SET TRANSACTION ISOLATION LEVEL READ
UNCOMMITTED pour éviter des locks de lecture dans des SELECT
- il y a ici (pub)
http://www.babaluga.org/doku.php/sql_server/administration/index un code
maison pour tracer les situations de blocage
Pour tracer les locks à mon sens le plus simple est passer par le Profiler SQL, cela fait parti des évennements qu'il sait tracer.
sp_lock est bien, mais présente une vision instantané de la chose et donc pas évident de se connecter au serveur et de tomber pile sur le lock.
Les compteurs de performance donnent aussi une assez bonne idée, tel que : o Average Wait Time (ms) o Lock Timeouts/sec o Number of Deadlocks/sec Ils permettent surtout de connaître la fréquence du problème.
Par contre je suis absolument contre l'usage des WITH(NOLOCK) et plus généralement de l'utilisation du niveau READ UNCOMMITED. EN effet ce niveau d'isolation provoque un risque fort d'erreur dans la base, étant donné qu'il permet la lecture de valeurs temporaires ou de travaille, ou de données erronnée qui vont être passées en ROLLBACK !
De plus en général, leur usage n'est pas réfléchis et on les retrouve dans quasiement toutes les requêtes par la suite.
Le plus simple pour éviter les problèmes de lock : - Limitez la durée des transactions, et démarrer votre transaction le plus tard possible (juste avant les commandes de mise à jour) et terminez là le plus tôt possible. - Quand cela est possible fragmentez les mises à jour par paquet (par bloc d'enregistrement, plutot que sur une table complète) - Limitez l'usage des triggers aux tables les moins fréquement mises à jours.
SQL Server 2005 propose un mode Snapshot qui solutionne aussi ce genre de problèmes.
-- Cordialement
Christian Robert Consultant - Formateur chez Winwise MCT - MCDBA - MCSD MCTS & MCITP SQL Server 2005
"Rudi Bruchez" <"rudi#nospam#[at]babaluga" a écrit :
Brigitte a écrit:
> Bonjour, > > Nous avons de problèmes de locks sur une table. > Comment tracer cela? > Comment régler cela? >
Bonjour,
le sujet est large. En détaillant un peu ton problème, nous pourrons donner des réponses plus spécifiques. Tu peux commencer avec : - sp_lock pour voir les verrous tenus à un instant T - qqch comme SELECT * FROM master.dbo.sysprocesses WHERE blocked > 0 (sur sql 2000) pour les processus qui attendent la libération de verrous, - WITH (READUNCOMMITTED) ou SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED pour éviter des locks de lecture dans des SELECT - il y a ici (pub) http://www.babaluga.org/doku.php/sql_server/administration/index un code maison pour tracer les situations de blocage
