sql server 2008-2016 - dominiqueverriere.fr · locks avec sql server sql server le blog de...

SQL Server 2008-2016

Dominique Verrière

Dialogue Formation Informatique

SQL Server 2008-2016

Locks avec SQL Server

SQL Server : Le blog de Dominique Verrière 2

Introduction

Ce petit fascicule fait partie d’une liste de notes que je publie gratuitement sur mon site.

J’essaie de mettre dans ces notes mon expérience de terrain en toute indépendance de Microsoft.

Dominique Verrière

Table des matières Locks avec SQL Server relationnel ................................................................................ 6

Introduction : ......................................................................................................................................................... 6

Compatibilité des verrous : ................................................................................................................................. 12

Pose de locks lors des Inserts : ............................................................................................................................ 13

Locks posés par les delete : ................................................................................................................................. 16

Locks posés par les update : ................................................................................................................................ 17

Les deadlocks : ..................................................................................................................................................... 17

Conclusion : ............................................................................................................... 19

Pour aller plus loin : ............................................................................................................................................. 19

Contacter l’auteur ...................................................................................................... 20

Sommaire



SQL Server Le blog de Dominique Verrière

Locks avec SQL Server relationnel

Introduction : Les LOCKS sont un des concepts les plus ‘secrets’ dans le monde SQL Server ; je vais essayer ici de démystifier

un peu cette notion.

Outils de surveillance :

On surveille les locks habituellement de deux façons :

Je vais utiliser ici une requête basée sur les DMV :

use master go if exists (select 1 from sys.databases where name = 'EtudeVerrouillage') drop database EtudeVerrouillage go create database EtudeVerrouillage -- que des bonnes pratiques ! go use EtudeVerrouillage go declare @IdSession1 int,@IdSession2 int set @IdSession1 = 57 set @IdSession2 = 51 select case request_session_id when @IdSession1 then 'Process A' when @IdSession2 then 'Process B' end as NomProcess,

1. Par un constat de ce qu’il y a actuellement : typiquement on va utiliser le moniteur d’activité ou la

procédure sp_locks ou une vue dynamique de gestion

2. Par un suivi de leur séquence d’acquisition : on se sert cette fois du profiler



resource_type as TypeRessource, case resource_type when 'DATABASE' then 1 when 'FILE' then 2 when 'OBJECT' then 3 when 'EXTENT' then 4 when 'PAGE' then 5 when 'KEY' then 6 when 'RID' then 7 when 'APPLICATION' then 8 when 'METADATA' then 9 when 'HOBT' then 10 when 'ALLOCATION_UNIT' then 11 end as Etendue, db_name(resource_database_id) as NomBase, case resource_type when 'DATABASE' then '' -- Néant when 'FILE' then '' -- Néant when 'OBJECT' then object_name(l.resource_associated_entity_id) -- ID de l'objet when 'PAGE' then object_name(p.object_id) --HoBt ID. Correspond à sys.partitions.hobt_id. when 'KEY' then object_name(p.object_id)--HoBt ID. Correspond à sys.partitions.hobt_id. when 'EXTENT' then '' -- Néant when 'RID' then object_name(p.object_id) -- HoBt ID. Correspond à sys.partitions.hobt_id. when 'APPLICATION' then '' -- Néant when 'METADATA' then '' -- Néant when 'HOBT' then object_name(p.object_id) -- HoBt ID. Correspond à sys.partitions.hobt_id. when 'ALLOCATION_UNIT' then '' --sys.allocation_units.allocation_unit_id. end as NomObjet, resource_description as Adresse, request_type as TypeDemande, request_status as EtatDemande, request_mode as ModeVerrouillage --,l.* --,p.* from sys.dm_tran_locks l left outer join sys.partitions p on l.resource_associated_entity_id = p.partition_id where (l.request_session_id = @IdSession1 or l.request_session_id = @IdSession2) and resource_database_id = db_id() order by NomProcess,etendue



C’est parti !

Faisons une simple connexion :

Quid du verrouillage :

Tiens, tiens… effectivement ce verrou S (Shared) au niveau de la base signalera que certaines opérations

telles un restore ne pourront être faites sans déconnecter cette session.

Un simple select

select * from dbo.Donnees where Cle = 1

Sachant que mon process est le B, il n’y a apparemment, pas de LOCKS ?

Pas si simple, en réalité la durée de vie des verrous est importante à considérer ; la plupart du temps, la

transaction, ici nous sommes en implicite, donc une instruction = une transaction, donc un lock très furtif (le

temps de l’exécution)

begin tran select * from dbo.Donnees where Cle = 1

Toujours pas de LOCKS ?



De nouveau, cela dépend du niveau d’isolation :

Par défaut, sur SQL Server, nous sommes en READ COMMITTED => toute donnée lue est libérée, ce qui

permet aux autres process de pouvoir travailler sur cette donnée.

Passons à un niveau d’isolation (ou d’isolement si vous voulez) plus élevé :

set transaction isolation level repeatable read begin tran select * from dbo.Donnees where Cle = 1

Ah :

On commence à voir ce dont il s’agit…

Que sont ces verrous d’intention ?

Ils servent à empêcher des concurrents de prendre une place s’il y a quelqu’un en dessous…dans mes cours,

je prends souvent l’image des travaux sous-marins :

Le bateau de surface qui gère un scaphandrier ne peut pas bouger sans entrainer un grave problème pour

celui-ci !

Par ailleurs cette notion importante va lui servir à ‘escalader’ la granularité de verrouillage :

READ UNCOMMITTED

READ COMMITTED

REPEATABLE READ

SNAPSHOT

SERIALIZABLE

1. Les lectures posent des LOCKS S (Shared) qui permettent aux autres de lire, pas de modifier

2. Ces verrous sont posés à une granularité (ici KEY) avec des verrous d’intention aux niveaux

supérieurs



En effet la pose et la gestion des verrous coûtent cher, et SQL Server va déterminer tout seul que poser

beaucoup de verrous ligne ou clé est coûteux et décidera donc au-delà d’un certain nombre de remonter au

niveau de l’objet (souvent la table, quelquefois la partition)

Voyons cela :

set transaction isolation level repeatable read begin tran select * from dbo.Donnees where Cle < 6000

Je lis donc moins de 6000 clés, les verrous sont :

Noter le 6029 en bas à droite…

Passons maintenant à 7000 clés :

set transaction isolation level repeatable read begin tran select * from dbo.Donnees where Cle < 7000



Voilà ce que l’on appelle un ‘lock escalation’ : on est passé de 6029 locks à 2 !

Formidable pour les performances, moins formidable pour la concurrence, en effet plus la granularité est

élevée, moins on laisse passer les autres process, mais plus on va vite à poser/enlever les verrous.

On voit que la remontée se fait directement au niveau objet, sans passer par le niveau page…. C’est ce que la

documentation en ligne dit, mais pas tous les ouvrages sur SQL Server …



Compatibilité des verrous : Les lectures sont compatibles entre elles (heureusement !) comme le montre cet exemple :

-- Process A select * from Donnees where Cle < 7000

-- Process B select * from Donnees where Cle < 7000

Par contre, lecture bloque mise à jour et vice versa :

-- Process A set transaction isolation level repeatable read begin tran select * from dbo.Donnees where Cle < 7000

-- Process B begin tran update dbo.Donnees set Valeur = '10 rue du chat qui dort' where Cle = 2

ZZZZZZZZ…..



Pose de locks lors des Inserts : begin tran insert into dbo.Donnees (Valeur) values ('25 rue des charmes')

Un verrou ligne donc… en X (exclusif) cela va de soit.

Les habituels Ix dans les niveaux supérieurs (de l’objet donc la table)

Tentons maintenant des Insert simultanés :

begin tran insert into dbo.Donnees (Valeur) values ('25 rue des charmes')

begin tran insert into dbo.Donnees (Valeur) values ('59 rue du Nord')

Vérifions ce qui s’est passé au niveau des locks :



Cela passe car les verrous sont posés au niveau clé.

Tentons des escalades de locks en mode insert :

begin tran declare @i int = 1 set nocount on while @i <= 20000 begin insert into dbo.Donnees (Valeur) values ('25 rue des charmes') set @i = @i +1 end

Visiblement, pas d’escalade en Insert : noter le 20091 à droite.



Une insertion de 200 000 lignes donnera donc :

Attention aux ressources !!!

On préférera sans doute (si le code source est modifiable…KS ?) :

begin tran declare @i int = 1 set nocount on while @i <= 200000 begin insert into dbo.Donnees with (tablockx) (Valeur) values ('25 rue des charmes') set @i = @i +1 end

Attention : on gagne ici en mémoire et sans doute en vitesse, mais on perd en concurrence …



A noter une nouveauté intéressante depuis SQL 2008 : pourra forcer les plans d’exécution sans modifier le

code source mais en citant simplement la requête (technique comparable à la mise en cache des

procédures)

Locks posés par les delete : Comme toute opération de mise à jour, nous allons avoir des X :

begin tran delete from dbo.Donnees where Cle between 5001 and 10000

Et là, on va avoir de nouveau des escalades :

begin tran delete from dbo.Donnees where Cle between 5001 and 30000

Donc, gare à la concurrence avec des delete en masse !



Locks posés par les update : Comme toute opération de mise à jour, nous allons avoir des X :

begin tran update dbo.Donnees set Valeur = UPPER(Valeur) where Cle between 5001 and 10000

Verrouillage au niveau ligne donc.

Et, de nouveau, le mécanisme d’escalade :

begin tran update dbo.Donnees set Valeur = UPPER(Valeur) where Cle between 5001 and 30000

Les deadlocks : Est-il besoin de revenir sur ce concept maintenant éculé ?

Bon…parce que c’est vous… un petit sur la même table :



begin tran update dbo.Donnees set Valeur = UPPER(Valeur) where Cle between 5001 and 5010 waitfor delay '00:00:10' update dbo.Donnees set Valeur = UPPER(Valeur) where Cle between 5011 and 5020

begin tran update dbo.Donnees set Valeur = UPPER(Valeur) where Cle between 5011 and 5020 waitfor delay '00:00:10' update dbo.Donnees set Valeur = UPPER(Valeur) where Cle between 5001 and 5010

Msg 1205, Niveau 13, État 51, Ligne 8 La transaction (ID de processus 58) a été bloquée sur les ressources verrou par un autre processus et a été choisie comme victime. Réexécutez la transaction.

Ce qui vous montre que l’on peut avoir des deadlocks avec une seule table …



Conclusion : Attention à :

Nota : l’escalade des verrous peut être désactivée par table depuis SQL2008.

Les deadlocks sont essentiellement dus (hormis ceux dus à l’escalade) au mode de programmation du

développeur.

Mon mode de gestion préféré de la concurrence est l’horodatage ou time stamping, je bloguerai peut être

là-dessus.

Pour aller plus loin :

Disponible ici :

Livre gérer la concurrence et les locks

1. La durée des transactions

2. Nombre de lignes mises à jour/détruites

3. Phénomène d’escalade des verrous

http://www.youscribe.com/catalogue/livres/ressources-professionnelles/informatique/sql-server-gerer-la-concurrence-et-les-locks-2837711

Contact


Contacter l’auteur

Dominique Verrière est un consultant spécialisé sur les technologies SQL Server : moteur relationnel, SSIS, SSRS et SSAS. Il intervient dans les entreprises pour des missions d'audit, de suivi de performances, d'administration de bases de données. Les bases de données dont il s'occupe peuvent contenir plusieurs milliards de lignes et atteindre des Téra octets; son expérience du terrain est donc significative. Afin de compléter cet article, un blog www.dominiqueverriere.fr est régulièrement mis à jour avec des articles sur les nouveautés ou expériences nouvelles de l'auteur

http://www.dominiqueverriere.fr/

sql server 2008-2016 - dominiqueverriere.fr · locks avec sql server sql server le blog de...

Documents