MSSQL 2000 : "Gestion des Locks" - Expert demandé ;-))
3 réponses
Florent G.
Bonjour,
Je rencontre actuellement des problèmes de tables "lockées" qui rendent les
performances de mes applications déplorables avec mon MSSQL2000sp3a sous
windows 2000 Server, voici ce que nous avons essayé pour mettre en évidence
un probleme de gestion des "Locks" de MSSQL2000.
Quelqu'un pourrait il me dire quefaire pour y remédier et arriver à une
gestion meilleure des Locks "à la ORACLE".
Merci d'avance
==========================================
Test réalisé montrant le problème d’accès concurrent avec SQL server 2000
(édition standard)
Il s’agit d’exécuter simultanément une transaction avec mise à jour dans une
table et une requête SELECT sur la même table en read commited. Le problème
est que le SELECT attend que la transaction se termine pour pouvoir
s’exécuter.
Le test à réaliser est le suivant :
1- Céer une table et insérer des données:
CREATE TABLE TOTO(
id int IDENTITY,
value varchar (256)
)
Exécuter n fois :
INSERT into TOTO (value) values ('DEZADAZdazekzfkezlmfzekfzfzekfkz')
2- Dans l’analyseur de requête, lancer une transaction réalisant une mise à
jour basique:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRAN
INSERT into TOTO (value) values ('DEZADAZdazekzfkezlmfzekfzfzekfkz')
résultat: (1 ligne(s) affectée(s))
3- Dans un autre analyseur de requête, lancer requête de lecture simple en
read commited:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
select * from TOTO
résultat : la requête ne retourne pas de réponse malgré le niveau
d’isolation read commited.
4- dans le 1er analyseur de requête, commiter la transaction.
COMMIT
Résultat : le select retourne imédiatement le résultat montrant ainsi que le
select était bien bloqué par la transaction en cours.
Bonjour, il vous suffit de mettre (NOLOCK) sur votre select
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
select * from TOTO (NOLOCK)
salutations
Bouarroudj Mohamed
> Quelqu'un pourrait il me dire quefaire pour y remédier et arriver à une gestion meilleure des Locks "à la ORACLE".
Je suis très curieux de savoir comment Oracle Magiquement résous le problème des Locks !
Avec SQL Server 2000 et 2005
1. Vous pouvez utiliser le hint WITH(NOLOCK) pour lire les enregistrements qui ne sont pas encore committées (dirty read)
Exp : select * from TOTO WITH(NOLOCK)
vous pouvez aussi utiliser SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
2. Vous pouvez dire a SQL Server d'ignorer les enregistrements lockées et ne retourner que les enregistrements qui n'ont aucun lock avec WITH(READPAST)
Exp : select * from TOTO WITH(READPAST)
Avec SQL Server 2005
vous pouvez utiliser SET TRANSACTION ISOLATION LEVEL SNAPSHOT pour lire la version originale de l'enregistrement qui est encours de modification
En quoi Oracle surpasse SQL Server ?
"Florent G." wrote in message news:
Bonjour,
Je rencontre actuellement des problèmes de tables "lockées" qui rendent les performances de mes applications déplorables avec mon MSSQL2000sp3a sous windows 2000 Server, voici ce que nous avons essayé pour mettre en évidence un probleme de gestion des "Locks" de MSSQL2000.
Quelqu'un pourrait il me dire quefaire pour y remédier et arriver à une gestion meilleure des Locks "à la ORACLE".
Merci d'avance
========================================= > Test réalisé montrant le problème d'accès concurrent avec SQL server 2000 (édition standard)
Il s'agit d'exécuter simultanément une transaction avec mise à jour dans une table et une requête SELECT sur la même table en read commited. Le problème est que le SELECT attend que la transaction se termine pour pouvoir s'exécuter.
Le test à réaliser est le suivant :
1- Céer une table et insérer des données:
CREATE TABLE TOTO( id int IDENTITY, value varchar (256) )
Exécuter n fois :
INSERT into TOTO (value) values ('DEZADAZdazekzfkezlmfzekfzfzekfkz')
2- Dans l'analyseur de requête, lancer une transaction réalisant une mise à jour basique:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRAN
INSERT into TOTO (value) values ('DEZADAZdazekzfkezlmfzekfzfzekfkz')
résultat: (1 ligne(s) affectée(s))
3- Dans un autre analyseur de requête, lancer requête de lecture simple en read commited:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
select * from TOTO
résultat : la requête ne retourne pas de réponse malgré le niveau d'isolation read commited.
4- dans le 1er analyseur de requête, commiter la transaction.
COMMIT
Résultat : le select retourne imédiatement le résultat montrant ainsi que le select était bien bloqué par la transaction en cours.
Florent
> Quelqu'un pourrait il me dire quefaire pour y remédier et arriver à une
gestion meilleure des Locks "à la ORACLE".
Je suis très curieux de savoir comment Oracle Magiquement résous le problème
des Locks !
Avec SQL Server 2000 et 2005
1. Vous pouvez utiliser le hint WITH(NOLOCK) pour lire les enregistrements
qui ne sont pas encore committées (dirty read)
Exp : select * from TOTO WITH(NOLOCK)
vous pouvez aussi utiliser SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
2. Vous pouvez dire a SQL Server d'ignorer les enregistrements lockées et ne
retourner que les enregistrements qui n'ont aucun lock avec WITH(READPAST)
Exp : select * from TOTO WITH(READPAST)
Avec SQL Server 2005
vous pouvez utiliser SET TRANSACTION ISOLATION LEVEL SNAPSHOT
pour lire la version originale de l'enregistrement qui est encours de
modification
En quoi Oracle surpasse SQL Server ?
"Florent G." <FlorentG@discussions.microsoft.com> wrote in message
news:B2A10259-9E9C-49B4-829E-B1BA753CB11F@microsoft.com...
Bonjour,
Je rencontre actuellement des problèmes de tables "lockées" qui rendent
les
performances de mes applications déplorables avec mon MSSQL2000sp3a sous
windows 2000 Server, voici ce que nous avons essayé pour mettre en
évidence
un probleme de gestion des "Locks" de MSSQL2000.
Quelqu'un pourrait il me dire quefaire pour y remédier et arriver à une
gestion meilleure des Locks "à la ORACLE".
Merci d'avance
========================================= > Test réalisé montrant le problème d'accès concurrent avec SQL server 2000
(édition standard)
Il s'agit d'exécuter simultanément une transaction avec mise à jour dans
une
table et une requête SELECT sur la même table en read commited. Le
problème
est que le SELECT attend que la transaction se termine pour pouvoir
s'exécuter.
Le test à réaliser est le suivant :
1- Céer une table et insérer des données:
CREATE TABLE TOTO(
id int IDENTITY,
value varchar (256)
)
Exécuter n fois :
INSERT into TOTO (value) values ('DEZADAZdazekzfkezlmfzekfzfzekfkz')
2- Dans l'analyseur de requête, lancer une transaction réalisant une mise
à
jour basique:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRAN
INSERT into TOTO (value) values ('DEZADAZdazekzfkezlmfzekfzfzekfkz')
résultat: (1 ligne(s) affectée(s))
3- Dans un autre analyseur de requête, lancer requête de lecture simple en
read commited:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
select * from TOTO
résultat : la requête ne retourne pas de réponse malgré le niveau
d'isolation read commited.
4- dans le 1er analyseur de requête, commiter la transaction.
COMMIT
Résultat : le select retourne imédiatement le résultat montrant ainsi que
le
select était bien bloqué par la transaction en cours.
> Quelqu'un pourrait il me dire quefaire pour y remédier et arriver à une gestion meilleure des Locks "à la ORACLE".
Je suis très curieux de savoir comment Oracle Magiquement résous le problème des Locks !
Avec SQL Server 2000 et 2005
1. Vous pouvez utiliser le hint WITH(NOLOCK) pour lire les enregistrements qui ne sont pas encore committées (dirty read)
Exp : select * from TOTO WITH(NOLOCK)
vous pouvez aussi utiliser SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
2. Vous pouvez dire a SQL Server d'ignorer les enregistrements lockées et ne retourner que les enregistrements qui n'ont aucun lock avec WITH(READPAST)
Exp : select * from TOTO WITH(READPAST)
Avec SQL Server 2005
vous pouvez utiliser SET TRANSACTION ISOLATION LEVEL SNAPSHOT pour lire la version originale de l'enregistrement qui est encours de modification
En quoi Oracle surpasse SQL Server ?
"Florent G." wrote in message news:
Bonjour,
Je rencontre actuellement des problèmes de tables "lockées" qui rendent les performances de mes applications déplorables avec mon MSSQL2000sp3a sous windows 2000 Server, voici ce que nous avons essayé pour mettre en évidence un probleme de gestion des "Locks" de MSSQL2000.
Quelqu'un pourrait il me dire quefaire pour y remédier et arriver à une gestion meilleure des Locks "à la ORACLE".
Merci d'avance
========================================= > Test réalisé montrant le problème d'accès concurrent avec SQL server 2000 (édition standard)
Il s'agit d'exécuter simultanément une transaction avec mise à jour dans une table et une requête SELECT sur la même table en read commited. Le problème est que le SELECT attend que la transaction se termine pour pouvoir s'exécuter.
Le test à réaliser est le suivant :
1- Céer une table et insérer des données:
CREATE TABLE TOTO( id int IDENTITY, value varchar (256) )
Exécuter n fois :
INSERT into TOTO (value) values ('DEZADAZdazekzfkezlmfzekfzfzekfkz')
2- Dans l'analyseur de requête, lancer une transaction réalisant une mise à jour basique:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRAN
INSERT into TOTO (value) values ('DEZADAZdazekzfkezlmfzekfzfzekfkz')
résultat: (1 ligne(s) affectée(s))
3- Dans un autre analyseur de requête, lancer requête de lecture simple en read commited:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
select * from TOTO
résultat : la requête ne retourne pas de réponse malgré le niveau d'isolation read commited.
4- dans le 1er analyseur de requête, commiter la transaction.
COMMIT
Résultat : le select retourne imédiatement le résultat montrant ainsi que le select était bien bloqué par la transaction en cours.
Florent
Med Bouchenafa
Dans SQL Server et en mode d'isolation READ COMMITTED, on ne peut lire que des enregistrements committés. C'est conforme à ce niveau d'isolation. Si l'on veut lire des enregistrements non committés, il faut passer au mode READ UNCOMMITTED qui comme son nom l'indique permet de lire des enregistrements qui ne sont pas validés Les deux autres posts de Philip et Mohamed t'ont indiqués comment on peut le faire avec des hints (NOLOCK, READPAST, etc...) Une autre technique consisterait à éviter de lire les enregistrements qui sont verrouillés en ajoutant une clause WHERE à ton second SELECT SELECT * FROM toto WHERE id < 100 Il te faut ajouer un index sur ta table toto sur la colonne id.
-- Avec mes meilleurs voeux 2006 Med Bouchenafa
"Florent G." a écrit dans le message de news:
Bonjour,
Je rencontre actuellement des problèmes de tables "lockées" qui rendent les performances de mes applications déplorables avec mon MSSQL2000sp3a sous windows 2000 Server, voici ce que nous avons essayé pour mettre en évidence un probleme de gestion des "Locks" de MSSQL2000.
Quelqu'un pourrait il me dire quefaire pour y remédier et arriver à une gestion meilleure des Locks "à la ORACLE".
Merci d'avance
========================================= > Test réalisé montrant le problème d'accès concurrent avec SQL server 2000 (édition standard)
Il s'agit d'exécuter simultanément une transaction avec mise à jour dans une table et une requête SELECT sur la même table en read commited. Le problème est que le SELECT attend que la transaction se termine pour pouvoir s'exécuter.
Le test à réaliser est le suivant :
1- Céer une table et insérer des données:
CREATE TABLE TOTO( id int IDENTITY, value varchar (256) )
Exécuter n fois :
INSERT into TOTO (value) values ('DEZADAZdazekzfkezlmfzekfzfzekfkz')
2- Dans l'analyseur de requête, lancer une transaction réalisant une mise à jour basique:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRAN
INSERT into TOTO (value) values ('DEZADAZdazekzfkezlmfzekfzfzekfkz')
résultat: (1 ligne(s) affectée(s))
3- Dans un autre analyseur de requête, lancer requête de lecture simple en read commited:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
select * from TOTO
résultat : la requête ne retourne pas de réponse malgré le niveau d'isolation read commited.
4- dans le 1er analyseur de requête, commiter la transaction.
COMMIT
Résultat : le select retourne imédiatement le résultat montrant ainsi que le select était bien bloqué par la transaction en cours.
Florent
Dans SQL Server et en mode d'isolation READ COMMITTED, on ne peut lire que
des enregistrements committés.
C'est conforme à ce niveau d'isolation.
Si l'on veut lire des enregistrements non committés, il faut passer au mode
READ UNCOMMITTED qui comme son nom l'indique permet de lire des
enregistrements qui ne sont pas validés
Les deux autres posts de Philip et Mohamed t'ont indiqués comment on peut le
faire avec des hints (NOLOCK, READPAST, etc...)
Une autre technique consisterait à éviter de lire les enregistrements qui
sont verrouillés en ajoutant une clause WHERE à ton second SELECT
SELECT * FROM toto WHERE id < 100
Il te faut ajouer un index sur ta table toto sur la colonne id.
--
Avec mes meilleurs voeux 2006
Med Bouchenafa
"Florent G." <FlorentG@discussions.microsoft.com> a écrit dans le message de
news: B2A10259-9E9C-49B4-829E-B1BA753CB11F@microsoft.com...
Bonjour,
Je rencontre actuellement des problèmes de tables "lockées" qui rendent
les
performances de mes applications déplorables avec mon MSSQL2000sp3a sous
windows 2000 Server, voici ce que nous avons essayé pour mettre en
évidence
un probleme de gestion des "Locks" de MSSQL2000.
Quelqu'un pourrait il me dire quefaire pour y remédier et arriver à une
gestion meilleure des Locks "à la ORACLE".
Merci d'avance
========================================= > Test réalisé montrant le problème d'accès concurrent avec SQL server 2000
(édition standard)
Il s'agit d'exécuter simultanément une transaction avec mise à jour dans
une
table et une requête SELECT sur la même table en read commited. Le
problème
est que le SELECT attend que la transaction se termine pour pouvoir
s'exécuter.
Le test à réaliser est le suivant :
1- Céer une table et insérer des données:
CREATE TABLE TOTO(
id int IDENTITY,
value varchar (256)
)
Exécuter n fois :
INSERT into TOTO (value) values ('DEZADAZdazekzfkezlmfzekfzfzekfkz')
2- Dans l'analyseur de requête, lancer une transaction réalisant une mise
à
jour basique:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRAN
INSERT into TOTO (value) values ('DEZADAZdazekzfkezlmfzekfzfzekfkz')
résultat: (1 ligne(s) affectée(s))
3- Dans un autre analyseur de requête, lancer requête de lecture simple en
read commited:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
select * from TOTO
résultat : la requête ne retourne pas de réponse malgré le niveau
d'isolation read commited.
4- dans le 1er analyseur de requête, commiter la transaction.
COMMIT
Résultat : le select retourne imédiatement le résultat montrant ainsi que
le
select était bien bloqué par la transaction en cours.
Dans SQL Server et en mode d'isolation READ COMMITTED, on ne peut lire que des enregistrements committés. C'est conforme à ce niveau d'isolation. Si l'on veut lire des enregistrements non committés, il faut passer au mode READ UNCOMMITTED qui comme son nom l'indique permet de lire des enregistrements qui ne sont pas validés Les deux autres posts de Philip et Mohamed t'ont indiqués comment on peut le faire avec des hints (NOLOCK, READPAST, etc...) Une autre technique consisterait à éviter de lire les enregistrements qui sont verrouillés en ajoutant une clause WHERE à ton second SELECT SELECT * FROM toto WHERE id < 100 Il te faut ajouer un index sur ta table toto sur la colonne id.
-- Avec mes meilleurs voeux 2006 Med Bouchenafa
"Florent G." a écrit dans le message de news:
Bonjour,
Je rencontre actuellement des problèmes de tables "lockées" qui rendent les performances de mes applications déplorables avec mon MSSQL2000sp3a sous windows 2000 Server, voici ce que nous avons essayé pour mettre en évidence un probleme de gestion des "Locks" de MSSQL2000.
Quelqu'un pourrait il me dire quefaire pour y remédier et arriver à une gestion meilleure des Locks "à la ORACLE".
Merci d'avance
========================================= > Test réalisé montrant le problème d'accès concurrent avec SQL server 2000 (édition standard)
Il s'agit d'exécuter simultanément une transaction avec mise à jour dans une table et une requête SELECT sur la même table en read commited. Le problème est que le SELECT attend que la transaction se termine pour pouvoir s'exécuter.
Le test à réaliser est le suivant :
1- Céer une table et insérer des données:
CREATE TABLE TOTO( id int IDENTITY, value varchar (256) )
Exécuter n fois :
INSERT into TOTO (value) values ('DEZADAZdazekzfkezlmfzekfzfzekfkz')
2- Dans l'analyseur de requête, lancer une transaction réalisant une mise à jour basique:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRAN
INSERT into TOTO (value) values ('DEZADAZdazekzfkezlmfzekfzfzekfkz')
résultat: (1 ligne(s) affectée(s))
3- Dans un autre analyseur de requête, lancer requête de lecture simple en read commited:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
select * from TOTO
résultat : la requête ne retourne pas de réponse malgré le niveau d'isolation read commited.
4- dans le 1er analyseur de requête, commiter la transaction.
COMMIT
Résultat : le select retourne imédiatement le résultat montrant ainsi que le select était bien bloqué par la transaction en cours.
