Erreur bizzard-transaction en READ COMMITTED qui lit les UNCOMMITT

Le READ_COMMITTED_SNAPSHOT, comme son nom l'indique plus ou moins, n'est
valable que pour les transactions en READ_COMMITTED
Selon qu'il est ON ou OFF, SQL Server utilise un mécanisme de verrouillage
optimistique ou pessimiste( row-versioning ou verrouillage classique)
Avec READ_COMMITTED_SNAPSHOT ON, (optimistique) c'est le row-versioning qui
est utilisé et toutes les instructions voient les données comme elles
étaient au démarrage de la transaction
Avec READ_COMMITTED_SNAPSHOT OFF (Pessimistique), c'est le verrouillage
classique de SQL Server

Dans ton cas, je n'ai pas vraiment d'explication
Bizarre effectivement....
Si la session B voit les données non committées c'est qu'elle utilise du
READ UNCOMMITTED et le READ_COMMITTED_SNAPSHOT n'a aucune influence

Cela change-t-il quelque chose si tu repassais en READ_COMMITTED_SNAPSHOT
OFF ?

Je lancerais à tout hasard un DBCC CHECKTABLE sur cette table

--
Bien Cordialement
Med Bouchenafa


"OLAPFOREVER" <OLAPFOREVER@discussions.microsoft.com> wrote in message
news:83BDF45F-4353-464F-820A-777B3E7593E5@microsoft.com...

SQL Server 2005 sp3 Enterprise 64
--------------------------------------------
Bonjour

Jai vraiment un situation étrange

Ma database est active avec SET READ_COMMITTED_SNAPSHOT ON.

Dans managment studio

J'execute un Insert dans une Session A sans commit ou rollback
ex:
use database1
BEGIN TRAN
INSERT INTO TABLE1 VALUES (1,2,3)

Toujours dans managment studio

J'execute un autre script Session B pour lire la meme table
ex:
use database1
SELECT * FROM TABLE1

SURPISE ! La Session B peut voir les données insérées dans la Session A
(uncommited)

Evidemment aussitot que j'applique un rollback dans la Session A , la
Session B ne retourne plus les données insérées en Session A

Sur un autre serveur tout va correctement
Le probleme survient seulement sur un seul de mes serveur
ET
sur ce serveur , dans la meme database , le probleme ne survient pas sur
une
autre table


J'ai essayé de forcer le READ COMMITTED dans la Sessio B
SET TRANSACTION ISOLATION LEVEL READ COMMITED
GO
BEGIN TRANSACTION;
SELECT * FROM TABLE1
COMMIT
GO
mais rien à faire ... meme probleme

Le seul cas qui fonctionne est si je force avec
SET TRANSACTION ISOLATION LEVEL SNAPSHOT

Quun peut m'aider à comprendre ?

Non, c'est tout à fait logique. Il a fait un COMMIT implicite dans le
premier cas et explicite dans l'autre. Ce sont deux COMMIT. or par
défaut il est dans le mode READ COMMITTED.
Il n'y a que si explicitement il entame une transaction au niveau
d'isolation SNAPSHOT que les choses se passeront comme il voudrait.

Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.co m/isolation-transaction/

A +

Frédéric BROUARD, Spécialiste modélisation, bases de données,
optimisation, langage SQL.
Le site sur le langage SQL et les S.G.B.D. relationnels :
http://sqlpro.developpez.com/
Expert SQL Server http://www.sqlspot.com : audit, optimisation,
tuning, formation
* * * * * Enseignant au CNAM PACA et à l'ISEN à Toulon * * * * *

On 27 mai, 15:29, OLAPFOREVER <OLAPFORE...@discussions.microsoft.com>
wrote:

SQL Server 2005 sp3 Enterprise 64
--------------------------------------------
Bonjour

Jai vraiment un situation étrange

Ma database est active avec SET READ_COMMITTED_SNAPSHOT ON.

Dans managment studio

J'execute un Insert dans une Session A sans commit ou rollback
ex:
use database1
BEGIN TRAN
INSERT INTO TABLE1 VALUES (1,2,3)

Toujours dans managment studio

J'execute un autre script Session B pour lire la meme table
ex:
use database1
SELECT * FROM TABLE1

SURPISE ! La Session B peut voir les données insérées dans la Ses sion A
(uncommited)

Evidemment aussitot que j'applique un rollback dans la Session A , la
Session B ne retourne plus les données insérées en Session A

Sur un autre serveur tout va correctement
Le probleme survient seulement sur un seul de mes serveur
ET
sur ce serveur , dans la meme database , le probleme ne survient pas sur une
autre table

J'ai essayé de forcer le READ COMMITTED dans la Sessio B
SET TRANSACTION ISOLATION LEVEL READ COMMITED
GO
BEGIN TRANSACTION;
SELECT * FROM TABLE1
COMMIT
GO
mais rien à faire ... meme probleme

Le seul cas qui fonctionne est si je force avec
SET TRANSACTION ISOLATION LEVEL SNAPSHOT

Quun peut m'aider à comprendre ?

Pourquoi ferait-il un commit implicite alors qu'il a bien mentionné
BEGIN TRAN
INSERT INTO TABLE1 VALUES (1,2,3)

Non, je ne comprends toujours pas pourquoi il a ce comportement bizarre
D'autant plus qu'il dit qu'il a ce comportement sur une table et pas sur une
autre
Effectivement tout se passe comme s'il avait un COMMIT mais il vient d'où

OLAPFOREVER, pourrais-tu ouvrir une troisième session et nous dire le
résultat de
DBCC OPEN
ou encore mieux de
SELECT * FROM sys.dm_tran_active_transactions

Pourrais-tu donne aussi le résultat de
SELECT name, compatibility_level, snapshot_isolation_state,
snapshot_isolation_state_desc, is_read_committed_snapshot_on
FROM sys.databases
WHERE name = 'database1'

Cela reste effectivement assez bizarre pour moi

--
Bien Cordialement
Med Bouchenafa

<brouardf@club-internet.fr> wrote in message
news:bbeddfcc-cf44-4e8e-a596-4b250cfb2a56@o20g2000vbh.googlegroups.com...
Non, c'est tout à fait logique. Il a fait un COMMIT implicite dans le
premier cas et explicite dans l'autre. Ce sont deux COMMIT. or par
défaut il est dans le mode READ COMMITTED.
Il n'y a que si explicitement il entame une transaction au niveau
d'isolation SNAPSHOT que les choses se passeront comme il voudrait.

Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/isolation-transaction/

A +

Frédéric BROUARD, Spécialiste modélisation, bases de données,
optimisation, langage SQL.
Le site sur le langage SQL et les S.G.B.D. relationnels :
http://sqlpro.developpez.com/
Expert SQL Server http://www.sqlspot.com : audit, optimisation,
tuning, formation
* * * * * Enseignant au CNAM PACA et à l'ISEN à Toulon * * * * *

On 27 mai, 15:29, OLAPFOREVER <OLAPFORE...@discussions.microsoft.com>
wrote:

SQL Server 2005 sp3 Enterprise 64
--------------------------------------------
Bonjour

Jai vraiment un situation étrange

Ma database est active avec SET READ_COMMITTED_SNAPSHOT ON.

Dans managment studio

J'execute un Insert dans une Session A sans commit ou rollback
ex:
use database1
BEGIN TRAN
INSERT INTO TABLE1 VALUES (1,2,3)

Toujours dans managment studio

J'execute un autre script Session B pour lire la meme table
ex:
use database1
SELECT * FROM TABLE1

SURPISE ! La Session B peut voir les données insérées dans la Session A
(uncommited)

Evidemment aussitot que j'applique un rollback dans la Session A , la
Session B ne retourne plus les données insérées en Session A

Sur un autre serveur tout va correctement
Le probleme survient seulement sur un seul de mes serveur
ET
sur ce serveur , dans la meme database , le probleme ne survient pas sur
une
autre table

J'ai essayé de forcer le READ COMMITTED dans la Sessio B
SET TRANSACTION ISOLATION LEVEL READ COMMITED
GO
BEGIN TRANSACTION;
SELECT * FROM TABLE1
COMMIT
GO
mais rien à faire ... meme probleme

Le seul cas qui fonctionne est si je force avec
SET TRANSACTION ISOLATION LEVEL SNAPSHOT

Quun peut m'aider à comprendre ?

Correction :
dans la code de Med, il faut lire :
DBCC OPENTRAN
et non DBCC OPEN.

A +


On 28 mai, 15:05, "Med Bouchenafa" <com.hotmail@bouchenafa> wrote:

Pourquoi ferait-il un commit implicite alors qu'il a bien mentionné
BEGIN TRAN
INSERT INTO TABLE1 VALUES (1,2,3)

Non, je ne comprends toujours pas pourquoi il a ce comportement bizarre
D'autant plus qu'il dit qu'il a ce comportement sur une table et pas sur une
autre
Effectivement tout se passe comme s'il avait un COMMIT mais il vient d'o ù

OLAPFOREVER, pourrais-tu ouvrir une troisième session  et nous dire l e
résultat de
DBCC OPEN
ou encore mieux de
SELECT * FROM sys.dm_tran_active_transactions

Pourrais-tu donne aussi le résultat de
SELECT name, compatibility_level, snapshot_isolation_state,
snapshot_isolation_state_desc, is_read_committed_snapshot_on
FROM sys.databases
WHERE name = 'database1'

Cela reste effectivement assez bizarre pour moi

--
Bien Cordialement
Med Bouchenafa

<broua...@club-internet.fr> wrote in message

news:bbeddfcc-cf44-4e8e-a596-4b250cfb2a56@o20g2000vbh.googlegroups.com...
Non, c'est tout à fait logique. Il a fait un COMMIT implicite dans le
premier cas et explicite dans l'autre. Ce sont deux COMMIT. or par
défaut il est dans le mode READ COMMITTED.
Il n'y a que si explicitement il entame une transaction au niveau
d'isolation SNAPSHOT que les choses se passeront comme il voudrait.

Lisez l'article que j'ai écrit à ce sujet :http://sqlpro.developpez.c om/isolation-transaction/

A +

Frédéric BROUARD, Spécialiste modélisation, bases de données,
optimisation, langage SQL.
Le site sur le langage SQL et les S.G.B.D. relationnels :http://sqlpro.de veloppez.com/
Expert SQL Serverhttp://www.sqlspot.com: audit, optimisation,
tuning, formation
* * * * * Enseignant au CNAM PACA et à l'ISEN à Toulon * * * * *

On 27 mai, 15:29, OLAPFOREVER <OLAPFORE...@discussions.microsoft.com>
wrote:

> SQL Server 2005 sp3 Enterprise 64
> --------------------------------------------
> Bonjour

> Jai vraiment  un situation étrange

> Ma  database est active  avec SET READ_COMMITTED_SNAPSHOT ON.

> Dans managment studio

> J'execute un Insert dans une Session A  sans  commit ou rollback
> ex:
> use database1
> BEGIN TRAN
> INSERT INTO TABLE1 VALUES (1,2,3)

> Toujours dans  managment studio

> J'execute un autre script Session B pour lire la meme table
> ex:
> use database1
> SELECT * FROM TABLE1

> SURPISE ! La Session B  peut voir  les données insérées dans la Session A
> (uncommited)

> Evidemment aussitot que j'applique un rollback dans la Session A , la
> Session B ne retourne plus les données insérées en Session A

> Sur un autre serveur tout va correctement
> Le probleme survient seulement sur un seul de mes serveur
> ET
> sur ce serveur , dans la meme database , le probleme ne survient pas su r
> une
> autre table

> J'ai essayé de forcer le READ COMMITTED dans la Sessio B
> SET TRANSACTION ISOLATION LEVEL READ COMMITED
> GO
> BEGIN TRANSACTION;
> SELECT *   FROM TABLE1
> COMMIT
> GO
> mais rien à faire ... meme probleme

> Le seul cas qui fonctionne est si je force avec
> SET TRANSACTION ISOLATION LEVEL SNAPSHOT

> Quun peut m'aider à comprendre ?

Oui, c'est le comportement normale du niveau d'isolation de gestion de
verions de lignes : Au lieu de proteger les données, sql server utilise lit
les données telles qu'ells existe aux moment de la lecture. Il n'y pas de
vérouiilage de lignes ici !


"OLAPFOREVER" <OLAPFOREVER@discussions.microsoft.com> a écrit dans le
message de news:83BDF45F-4353-464F-820A-777B3E7593E5@microsoft.com...

SQL Server 2005 sp3 Enterprise 64
--------------------------------------------
Bonjour

Jai vraiment un situation étrange

Ma database est active avec SET READ_COMMITTED_SNAPSHOT ON.

Dans managment studio

J'execute un Insert dans une Session A sans commit ou rollback
ex:
use database1
BEGIN TRAN
INSERT INTO TABLE1 VALUES (1,2,3)

Toujours dans managment studio

J'execute un autre script Session B pour lire la meme table
ex:
use database1
SELECT * FROM TABLE1

SURPISE ! La Session B peut voir les données insérées dans la Session A
(uncommited)

Evidemment aussitot que j'applique un rollback dans la Session A , la
Session B ne retourne plus les données insérées en Session A

Sur un autre serveur tout va correctement
Le probleme survient seulement sur un seul de mes serveur
ET
sur ce serveur , dans la meme database , le probleme ne survient pas sur
une
autre table


J'ai essayé de forcer le READ COMMITTED dans la Sessio B
SET TRANSACTION ISOLATION LEVEL READ COMMITED
GO
BEGIN TRANSACTION;
SELECT * FROM TABLE1
COMMIT
GO
mais rien à faire ... meme probleme

Le seul cas qui fonctionne est si je force avec
SET TRANSACTION ISOLATION LEVEL SNAPSHOT

Quun peut m'aider à comprendre ?