Question

Quelles sont les règles de portée pour les niveaux d'isolation de transaction dans SQL Server 2005? Je sais ce que signifient les différents niveaux, mais je ne sais pas comment les appliquer correctement en dehors d'un script exécuté manuellement. Je ne trouve pas de guide d'utilisation pratique dans un code de qualité de production.

Évidemment, la portée commence lorsque vous utilisez une commande comme celle-ci:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED 

Mais où finit-il? Si je définis le niveau iso dans une procédure stockée et que ce proc en appelle un autre, le proc imbriqué en hérite-t-il? Mieux encore, si j'augmente le niveau ISO dans le processus imbriqué, est-ce que cela va se répercuter dans le processus appelant? Des commandes de transaction telles que BEGIN TRAN, ROLLBACK et COMMIT font-elles une différence?

Lorsqu'un processus stocké est appelé par une application ou un travail d'agent, les modifications du niveau d'isolation persistent-elles d'une manière ou d'une autre? Dois-je toujours revenir à la valeur par défaut READ COMMITTED à la fin de chaque procédure?

Je le testerais dans différentes situations, mais je ne sais pas comment lire le niveau d'isolation actuel.

Était-ce utile?

La solution

Exécutez ce qui suit et voyez par vous-même:

CREATE PROCEDURE dbo.KeepsIsolation
AS
BEGIN
PRINT 'Inside sproc that does not change isolation level';
DBCC USEROPTIONS;
END
GO

CREATE PROCEDURE dbo.ChangesIsolation
AS
BEGIN
PRINT 'Inside sproc that changes isolation level';
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
DBCC USEROPTIONS;
END
GO
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
DBCC USEROPTIONS;
EXEC dbo.KeepsIsolation;
DBCC USEROPTIONS;
EXEC dbo.ChangesIsolation;
-- demonstrates that isolation level restored to REPEATABLE READ after exiting the procedure
    DBCC USEROPTIONS;

Autres conseils

De MSDN

  

Si vous émettez SET TRANSACTION ISOLATION LEVEL dans une procédure stockée ou   déclencheur, lorsque l'objet retourne contrôler le niveau d'isolement est réinitialisé   au niveau en vigueur lorsque l'objet a été appelé . Par exemple, si   vous définissez REPEATABLE READ dans un lot, et le lot appelle ensuite un   procédure qui définit le niveau d’isolement sur SERIALIZABLE, l’isolement   paramètre de niveau revient à REPEATABLE READ lorsque la procédure stockée   renvoie le contrôle au lot.

DBCC USEROPTIONS affichera le niveau d'isolation actuel, ainsi que toutes les autres options SET.

À partir de livres en ligne

  

Un seul des ISOLEMENT DE TRANSACTION   Les options LEVEL peuvent être définies à la fois,   et il reste réglé pour cette connexion   jusqu'à ce qu'il soit explicitement changé. Ce   devient le comportement par défaut sauf si un   l'option d'optimisation est spécifiée à   le niveau de la table dans la clause FROM de   la déclaration.

Le niveau d'isolement n'est pas restauré avec la transaction.

Le niveau d'isolement reste actuel même si vous appelez des procédures et des fonctions.

Notez que la portée de TRANSACTION LEVELS et de SqlServer 2012 ou version antérieure pose un problème lorsque le regroupement de connexions ADO.NET hautes performances est utilisé là où il peut persister lors de la fermeture de la connexion:

SQL Server: le niveau d'isolement fuit au travers des connexions en pool

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/916b3d8a-c464-4ad5-8901-6f845a2a3447/sql-server-144-4-4ad5-8901-6f845a2a3447 / niveau = forum = sqldatabaseengine

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top