Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Windows Windows Serveur SQL Serveur Problème avec rowlock et updlock

Problème avec rowlock et updlock

6 réponses
Avatar
AJ
J'ai un comportement très étrange. Sous SqlServer 2005 SP1, sur une base en
mode SNAPSHOT ON.
Sur une première transaction, à partir de SQL Server Management Studio :
begin transaction
set transaction isolation level read committed
select * from table1 with (updlock, rowlock, nowait) where c1="XX" and c2=1
Dans ma base, j'obtiens ainsi 7 rangs. Je garde la transaction ouverte, sans
commit ni rollback.

Sur une deuxième transaction (i.e. sur un autre PC), toujours à partir de
SQL Server Management Studio :
begin transaction
set transaction isolation level read committed
select * from table1 with (updlock, rowlock, nowait) where c1="XX" and c2=2
Dans ma base, j'obtiens alors 21 rangs, et le message d'erreur "1222:Délai
de requête de verrou dépassé", alors que dans ma table, cette requête là doit
me retourner 28 rangs. Il m'en manque 7, comme par hasard. Bien entendu, si
je retire le nowait de cette requête, je reste en attente.

Pourtant avec ma clause where, ainsi qu'avec le lock par enregistrement
utilisé, il ne devrait pas y avoir de conflit.

J'ai soupçonné une escalade de verrou, j'ai donc surveillé avec sql server
profiler les event relatifs à l'escalade de verrous. J'ai rien vu. Donc, à
priori, il n'y a pas de passage en verrou de page.

Donc, là, je comprends pas trop. Soit c'est une belle bug de sql server,
soit y'a un truc que j'ai pas compris.

Si quelqu'un a une idée ... Parce que là, avec un comportement pareil, on va
être obligé d'abandonner le portage sous Sql Server de notre progiciel qui
tourne très bien sous Oracle. Et impossible de changer le mode de
fonctionnement de notre progiciel au niveau de la gestion des conflits
d'accès.

En plus, ce phénomène curieux, je le reproduit à souhait sur plusieurs
serveurs différents. J'exporte les données, et je les réimporte, et zou, même
comportement.

Etrange ???
Signaler un problème avec ce contenu

6 réponses

Supprimer
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
Avatar
Thierry
Bonjour,

Utilises Holdlock au lieu de Updlock.


--
Thierry


"AJ" a écrit dans le message de news:

J'ai un comportement très étrange. Sous SqlServer 2005 SP1, sur une base
en
mode SNAPSHOT ON.
Sur une première transaction, à partir de SQL Server Management Studio :
begin transaction
set transaction isolation level read committed
select * from table1 with (updlock, rowlock, nowait) where c1="XX" and
c2=1
Dans ma base, j'obtiens ainsi 7 rangs. Je garde la transaction ouverte,
sans
commit ni rollback.

Sur une deuxième transaction (i.e. sur un autre PC), toujours à partir de
SQL Server Management Studio :
begin transaction
set transaction isolation level read committed
select * from table1 with (updlock, rowlock, nowait) where c1="XX" and
c2=2
Dans ma base, j'obtiens alors 21 rangs, et le message d'erreur "1222:Délai
de requête de verrou dépassé", alors que dans ma table, cette requête là
doit
me retourner 28 rangs. Il m'en manque 7, comme par hasard. Bien entendu,
si
je retire le nowait de cette requête, je reste en attente.

Pourtant avec ma clause where, ainsi qu'avec le lock par enregistrement
utilisé, il ne devrait pas y avoir de conflit.

J'ai soupçonné une escalade de verrou, j'ai donc surveillé avec sql server
profiler les event relatifs à l'escalade de verrous. J'ai rien vu. Donc, à
priori, il n'y a pas de passage en verrou de page.

Donc, là, je comprends pas trop. Soit c'est une belle bug de sql server,
soit y'a un truc que j'ai pas compris.

Si quelqu'un a une idée ... Parce que là, avec un comportement pareil, on
va
être obligé d'abandonner le portage sous Sql Server de notre progiciel qui
tourne très bien sous Oracle. Et impossible de changer le mode de
fonctionnement de notre progiciel au niveau de la gestion des conflits
d'accès.

En plus, ce phénomène curieux, je le reproduit à souhait sur plusieurs
serveurs différents. J'exporte les données, et je les réimporte, et zou,
même
comportement.

Etrange ???








Avatar
AJ
Merci pour votre réponse, j'ai essayé, mais ça ne résoud pas mon problème.
Car si je fais un select avec (updlock,nowait) sur des enregistrement déjà
lockés, je dois me prendre une erreur Sql Server. Le code de mon progiciel
est prévu pour réagir à cette situation et prévenir l'opérateur que quelqu'un
d'autre utilise les données.

Avec le holdlock à la place du updlock, je n'ai plus d'erreur en cas de
conflict effectif.

Dominique.

"Thierry" a écrit :

Bonjour,

Utilises Holdlock au lieu de Updlock.


--
Thierry


"AJ" a écrit dans le message de news:

> J'ai un comportement très étrange. Sous SqlServer 2005 SP1, sur une base
> en
> mode SNAPSHOT ON.
> Sur une première transaction, à partir de SQL Server Management Studio :
> begin transaction
> set transaction isolation level read committed
> select * from table1 with (updlock, rowlock, nowait) where c1="XX" and
> c2=1
> Dans ma base, j'obtiens ainsi 7 rangs. Je garde la transaction ouverte,
> sans
> commit ni rollback.
>
> Sur une deuxième transaction (i.e. sur un autre PC), toujours à partir de
> SQL Server Management Studio :
> begin transaction
> set transaction isolation level read committed
> select * from table1 with (updlock, rowlock, nowait) where c1="XX" and
> c2=2
> Dans ma base, j'obtiens alors 21 rangs, et le message d'erreur "1222:Délai
> de requête de verrou dépassé", alors que dans ma table, cette requête là
> doit
> me retourner 28 rangs. Il m'en manque 7, comme par hasard. Bien entendu,
> si
> je retire le nowait de cette requête, je reste en attente.
>
> Pourtant avec ma clause where, ainsi qu'avec le lock par enregistrement
> utilisé, il ne devrait pas y avoir de conflit.
>
> J'ai soupçonné une escalade de verrou, j'ai donc surveillé avec sql server
> profiler les event relatifs à l'escalade de verrous. J'ai rien vu. Donc, à
> priori, il n'y a pas de passage en verrou de page.
>
> Donc, là, je comprends pas trop. Soit c'est une belle bug de sql server,
> soit y'a un truc que j'ai pas compris.
>
> Si quelqu'un a une idée ... Parce que là, avec un comportement pareil, on
> va
> être obligé d'abandonner le portage sous Sql Server de notre progiciel qui
> tourne très bien sous Oracle. Et impossible de changer le mode de
> fonctionnement de notre progiciel au niveau de la gestion des conflits
> d'accès.
>
> En plus, ce phénomène curieux, je le reproduit à souhait sur plusieurs
> serveurs différents. J'exporte les données, et je les réimporte, et zou,
> même
> comportement.
>
> Etrange ???
>
>
>
>
>
>





Avatar
lionelp
mettre une base en ALLOW_SNAPSHOT_ISOLATION indique que les transactions
peuvent utiliser ce mode, ça ne veut pas dire qu'elles l'utilise. Dans ton
cas le mode est read committed donc verrouillage par défaut.

pour avoir le row versioning par défault il faut mettre la base en
READ_COMMITTED_SNAPSHOT

Cordialement,
LionelP

"AJ" a écrit :

J'ai un comportement très étrange. Sous SqlServer 2005 SP1, sur une base en
mode SNAPSHOT ON.
Sur une première transaction, à partir de SQL Server Management Studio :
begin transaction
set transaction isolation level read committed
select * from table1 with (updlock, rowlock, nowait) where c1="XX" and c2=1
Dans ma base, j'obtiens ainsi 7 rangs. Je garde la transaction ouverte, sans
commit ni rollback.

Sur une deuxième transaction (i.e. sur un autre PC), toujours à partir de
SQL Server Management Studio :
begin transaction
set transaction isolation level read committed
select * from table1 with (updlock, rowlock, nowait) where c1="XX" and c2=2
Dans ma base, j'obtiens alors 21 rangs, et le message d'erreur "1222:Délai
de requête de verrou dépassé", alors que dans ma table, cette requête là doit
me retourner 28 rangs. Il m'en manque 7, comme par hasard. Bien entendu, si
je retire le nowait de cette requête, je reste en attente.

Pourtant avec ma clause where, ainsi qu'avec le lock par enregistrement
utilisé, il ne devrait pas y avoir de conflit.

J'ai soupçonné une escalade de verrou, j'ai donc surveillé avec sql server
profiler les event relatifs à l'escalade de verrous. J'ai rien vu. Donc, à
priori, il n'y a pas de passage en verrou de page.

Donc, là, je comprends pas trop. Soit c'est une belle bug de sql server,
soit y'a un truc que j'ai pas compris.

Si quelqu'un a une idée ... Parce que là, avec un comportement pareil, on va
être obligé d'abandonner le portage sous Sql Server de notre progiciel qui
tourne très bien sous Oracle. Et impossible de changer le mode de
fonctionnement de notre progiciel au niveau de la gestion des conflits
d'accès.

En plus, ce phénomène curieux, je le reproduit à souhait sur plusieurs
serveurs différents. J'exporte les données, et je les réimporte, et zou, même
comportement.

Etrange ???








Avatar
AJ
Merci pour votre réponse.
Mais ma base est bien en read_committed_snapshot.

J'ai isolé le problème. Le script ci-dessous reproduit à souhait le
comportement bizarre de sql server en rowlock.

--
-- Problem : ROWLOCK with SQL SERVER 2005
--
create table adt (id integer, nom varchar(50))
insert into adt (id, nom) values (1, 'A')
insert into adt (id, nom) values (2, 'B')
select * from adt
----------------------------------------------------
-- on first workstation
begin transaction
select nom from adt with (updlock, rowlock, nowait) where id = 1
----------------------------------------------------
-- on second workstation
begin transaction
select nom from adt with (updlock, rowlock, nowait) where id = 2
-- I've got an error...
-- Msg 1222, Level 16, Status 45, Line 3
-- Délai de requête de verrou dépassé.
-- ?????????????????????????????????????????????????

J'ai sousmis le problème à une personne du "EMEA GTSC SQL Support Engineer".

Malheureusement, c'est le comportement de sql server, pas de correctif la
dessus à l'horizon. Pour que cela marche, il faut que le parcours des tables
pour récupérer les rangs passe par un index qui lui evite de "déborder sur
d'autres rangs".
sql> create index testidx on adt(id)
sql> select nom from adt with (index=testidx,updlock, rowlock) where id = 1
Comme ça , ça marche. Si Oracle apprend ça, il va bien rigoler.

Cordialement
Dominique



"" a écrit :


mettre une base en ALLOW_SNAPSHOT_ISOLATION indique que les transactions
peuvent utiliser ce mode, ça ne veut pas dire qu'elles l'utilise. Dans ton
cas le mode est read committed donc verrouillage par défaut.

pour avoir le row versioning par défault il faut mettre la base en
READ_COMMITTED_SNAPSHOT

Cordialement,
LionelP

"AJ" a écrit :

> J'ai un comportement très étrange. Sous SqlServer 2005 SP1, sur une base en
> mode SNAPSHOT ON.
> Sur une première transaction, à partir de SQL Server Management Studio :
> begin transaction
> set transaction isolation level read committed
> select * from table1 with (updlock, rowlock, nowait) where c1="XX" and c2=1
> Dans ma base, j'obtiens ainsi 7 rangs. Je garde la transaction ouverte, sans
> commit ni rollback.
>
> Sur une deuxième transaction (i.e. sur un autre PC), toujours à partir de
> SQL Server Management Studio :
> begin transaction
> set transaction isolation level read committed
> select * from table1 with (updlock, rowlock, nowait) where c1="XX" and c2=2
> Dans ma base, j'obtiens alors 21 rangs, et le message d'erreur "1222:Délai
> de requête de verrou dépassé", alors que dans ma table, cette requête là doit
> me retourner 28 rangs. Il m'en manque 7, comme par hasard. Bien entendu, si
> je retire le nowait de cette requête, je reste en attente.
>
> Pourtant avec ma clause where, ainsi qu'avec le lock par enregistrement
> utilisé, il ne devrait pas y avoir de conflit.
>
> J'ai soupçonné une escalade de verrou, j'ai donc surveillé avec sql server
> profiler les event relatifs à l'escalade de verrous. J'ai rien vu. Donc, à
> priori, il n'y a pas de passage en verrou de page.
>
> Donc, là, je comprends pas trop. Soit c'est une belle bug de sql server,
> soit y'a un truc que j'ai pas compris.
>
> Si quelqu'un a une idée ... Parce que là, avec un comportement pareil, on va
> être obligé d'abandonner le portage sous Sql Server de notre progiciel qui
> tourne très bien sous Oracle. Et impossible de changer le mode de
> fonctionnement de notre progiciel au niveau de la gestion des conflits
> d'accès.
>
> En plus, ce phénomène curieux, je le reproduit à souhait sur plusieurs
> serveurs différents. J'exporte les données, et je les réimporte, et zou, même
> comportement.
>
> Etrange ???
>
>
>
>
>
>


Avatar
lionelp
au vu du scenario:
si pas d'index alors il y a un table scan, si sur ce table scan on demande
de tenir les locks posés alors toute la table est lockée quelque soit le type
d'isolation.
ce n'est pas un bug, c'est le comportement attendu.

Cordialement,
LionelP

"AJ" a écrit :

Merci pour votre réponse.
Mais ma base est bien en read_committed_snapshot.

J'ai isolé le problème. Le script ci-dessous reproduit à souhait le
comportement bizarre de sql server en rowlock.

--
-- Problem : ROWLOCK with SQL SERVER 2005
--
create table adt (id integer, nom varchar(50))
insert into adt (id, nom) values (1, 'A')
insert into adt (id, nom) values (2, 'B')
select * from adt
----------------------------------------------------
-- on first workstation
begin transaction
select nom from adt with (updlock, rowlock, nowait) where id = 1
----------------------------------------------------
-- on second workstation
begin transaction
select nom from adt with (updlock, rowlock, nowait) where id = 2
-- I've got an error...
-- Msg 1222, Level 16, Status 45, Line 3
-- Délai de requête de verrou dépassé.
-- ?????????????????????????????????????????????????

J'ai sousmis le problème à une personne du "EMEA GTSC SQL Support Engineer".

Malheureusement, c'est le comportement de sql server, pas de correctif la
dessus à l'horizon. Pour que cela marche, il faut que le parcours des tables
pour récupérer les rangs passe par un index qui lui evite de "déborder sur
d'autres rangs".
sql> create index testidx on adt(id)
sql> select nom from adt with (index=testidx,updlock, rowlock) where id = 1
Comme ça , ça marche. Si Oracle apprend ça, il va bien rigoler.

Cordialement
Dominique



"" a écrit :

>
> mettre une base en ALLOW_SNAPSHOT_ISOLATION indique que les transactions
> peuvent utiliser ce mode, ça ne veut pas dire qu'elles l'utilise. Dans ton
> cas le mode est read committed donc verrouillage par défaut.
>
> pour avoir le row versioning par défault il faut mettre la base en
> READ_COMMITTED_SNAPSHOT
>
> Cordialement,
> LionelP
>
> "AJ" a écrit :
>
> > J'ai un comportement très étrange. Sous SqlServer 2005 SP1, sur une base en
> > mode SNAPSHOT ON.
> > Sur une première transaction, à partir de SQL Server Management Studio :
> > begin transaction
> > set transaction isolation level read committed
> > select * from table1 with (updlock, rowlock, nowait) where c1="XX" and c2=1
> > Dans ma base, j'obtiens ainsi 7 rangs. Je garde la transaction ouverte, sans
> > commit ni rollback.
> >
> > Sur une deuxième transaction (i.e. sur un autre PC), toujours à partir de
> > SQL Server Management Studio :
> > begin transaction
> > set transaction isolation level read committed
> > select * from table1 with (updlock, rowlock, nowait) where c1="XX" and c2=2
> > Dans ma base, j'obtiens alors 21 rangs, et le message d'erreur "1222:Délai
> > de requête de verrou dépassé", alors que dans ma table, cette requête là doit
> > me retourner 28 rangs. Il m'en manque 7, comme par hasard. Bien entendu, si
> > je retire le nowait de cette requête, je reste en attente.
> >
> > Pourtant avec ma clause where, ainsi qu'avec le lock par enregistrement
> > utilisé, il ne devrait pas y avoir de conflit.
> >
> > J'ai soupçonné une escalade de verrou, j'ai donc surveillé avec sql server
> > profiler les event relatifs à l'escalade de verrous. J'ai rien vu. Donc, à
> > priori, il n'y a pas de passage en verrou de page.
> >
> > Donc, là, je comprends pas trop. Soit c'est une belle bug de sql server,
> > soit y'a un truc que j'ai pas compris.
> >
> > Si quelqu'un a une idée ... Parce que là, avec un comportement pareil, on va
> > être obligé d'abandonner le portage sous Sql Server de notre progiciel qui
> > tourne très bien sous Oracle. Et impossible de changer le mode de
> > fonctionnement de notre progiciel au niveau de la gestion des conflits
> > d'accès.
> >
> > En plus, ce phénomène curieux, je le reproduit à souhait sur plusieurs
> > serveurs différents. J'exporte les données, et je les réimporte, et zou, même
> > comportement.
> >
> > Etrange ???
> >
> >
> >
> >
> >
> >


Avatar
AJ
J'ai bien compris que ce n'était pas un bug, mais le comportement programmé
de sql server. Mais, je tiens à signaler, qu'Oracle n'a pas ce comportement
là dans ce type de situation. Et que, pour nous, éditeur de logiciel de
gestion avec contrôle d'accès par rowlock, le comportement de sql server nous
impose plus de travail en développement, qu'avec Oracle.

Pour moi, le meilleur des comportements est celui d'Oracle. Donc si sql
server peut s'en inspirer à terme, tant mieux.
Cordialement.
Dominique
"" a écrit :

au vu du scenario:
si pas d'index alors il y a un table scan, si sur ce table scan on demande
de tenir les locks posés alors toute la table est lockée quelque soit le type
d'isolation.
ce n'est pas un bug, c'est le comportement attendu.

Cordialement,
LionelP

"AJ" a écrit :

> Merci pour votre réponse.
> Mais ma base est bien en read_committed_snapshot.
>
> J'ai isolé le problème. Le script ci-dessous reproduit à souhait le
> comportement bizarre de sql server en rowlock.
>
> --
> -- Problem : ROWLOCK with SQL SERVER 2005
> --
> create table adt (id integer, nom varchar(50))
> insert into adt (id, nom) values (1, 'A')
> insert into adt (id, nom) values (2, 'B')
> select * from adt
> ----------------------------------------------------
> -- on first workstation
> begin transaction
> select nom from adt with (updlock, rowlock, nowait) where id = 1
> ----------------------------------------------------
> -- on second workstation
> begin transaction
> select nom from adt with (updlock, rowlock, nowait) where id = 2
> -- I've got an error...
> -- Msg 1222, Level 16, Status 45, Line 3
> -- Délai de requête de verrou dépassé.
> -- ?????????????????????????????????????????????????
>
> J'ai sousmis le problème à une personne du "EMEA GTSC SQL Support Engineer".
>
> Malheureusement, c'est le comportement de sql server, pas de correctif la
> dessus à l'horizon. Pour que cela marche, il faut que le parcours des tables
> pour récupérer les rangs passe par un index qui lui evite de "déborder sur
> d'autres rangs".
> sql> create index testidx on adt(id)
> sql> select nom from adt with (index=testidx,updlock, rowlock) where id = 1
> Comme ça , ça marche. Si Oracle apprend ça, il va bien rigoler.
>
> Cordialement
> Dominique
>
>
>
> "" a écrit :
>
> >
> > mettre une base en ALLOW_SNAPSHOT_ISOLATION indique que les transactions
> > peuvent utiliser ce mode, ça ne veut pas dire qu'elles l'utilise. Dans ton
> > cas le mode est read committed donc verrouillage par défaut.
> >
> > pour avoir le row versioning par défault il faut mettre la base en
> > READ_COMMITTED_SNAPSHOT
> >
> > Cordialement,
> > LionelP
> >
> > "AJ" a écrit :
> >
> > > J'ai un comportement très étrange. Sous SqlServer 2005 SP1, sur une base en
> > > mode SNAPSHOT ON.
> > > Sur une première transaction, à partir de SQL Server Management Studio :
> > > begin transaction
> > > set transaction isolation level read committed
> > > select * from table1 with (updlock, rowlock, nowait) where c1="XX" and c2=1
> > > Dans ma base, j'obtiens ainsi 7 rangs. Je garde la transaction ouverte, sans
> > > commit ni rollback.
> > >
> > > Sur une deuxième transaction (i.e. sur un autre PC), toujours à partir de
> > > SQL Server Management Studio :
> > > begin transaction
> > > set transaction isolation level read committed
> > > select * from table1 with (updlock, rowlock, nowait) where c1="XX" and c2=2
> > > Dans ma base, j'obtiens alors 21 rangs, et le message d'erreur "1222:Délai
> > > de requête de verrou dépassé", alors que dans ma table, cette requête là doit
> > > me retourner 28 rangs. Il m'en manque 7, comme par hasard. Bien entendu, si
> > > je retire le nowait de cette requête, je reste en attente.
> > >
> > > Pourtant avec ma clause where, ainsi qu'avec le lock par enregistrement
> > > utilisé, il ne devrait pas y avoir de conflit.
> > >
> > > J'ai soupçonné une escalade de verrou, j'ai donc surveillé avec sql server
> > > profiler les event relatifs à l'escalade de verrous. J'ai rien vu. Donc, à
> > > priori, il n'y a pas de passage en verrou de page.
> > >
> > > Donc, là, je comprends pas trop. Soit c'est une belle bug de sql server,
> > > soit y'a un truc que j'ai pas compris.
> > >
> > > Si quelqu'un a une idée ... Parce que là, avec un comportement pareil, on va
> > > être obligé d'abandonner le portage sous Sql Server de notre progiciel qui
> > > tourne très bien sous Oracle. Et impossible de changer le mode de
> > > fonctionnement de notre progiciel au niveau de la gestion des conflits
> > > d'accès.
> > >
> > > En plus, ce phénomène curieux, je le reproduit à souhait sur plusieurs
> > > serveurs différents. J'exporte les données, et je les réimporte, et zou, même
> > > comportement.
> > >
> > > Etrange ???
> > >
> > >
> > >
> > >
> > >
> > >