Choix des niveaux d'isolement selon le versioning de ligne
Les niveaux d'isolement dépendant du versioning de ligne améliorent la simultanéité en lecture en éliminant les verrous pour les opérations de lecture. Microsoft SQL Server 2005 propose deux nouveaux niveaux d'isolement de transaction utilisant le versioning de ligne :
- Une nouvelle mise en œuvre de l'isolement de lecture validée qui utilise le versioning de ligne lorsque l'option de base de données READ_COMMITTED_SNAPSHOT est ON.
- Un nouveau niveau d'isolement, l'isolement de capture instantanée, qui est activé lorsque l'option de base de données ALLOW_SNAPSHOT_ISOLATION est ON.
Pour la plupart des applications, l'isolement de lecture validée utilisant le versioning de ligne est préférable à l'isolement de capture instantanée pour les raisons suivantes :
- Il consomme moins d'espace tempdb que l'isolement de capture instantanée.
- Il fonctionne avec des transactions distribuées, ce qui n'est pas le cas de l'isolement de capture instantanée.
- Il fonctionne avec la plupart des applications existantes sans aucune modification. Les applications écrites avec le niveau d'isolement par défaut, l'isolement de lecture validée, peuvent être paramétrées dynamiquement. Le comportement de la lecture validée, s'il faut utiliser le versioning de ligne ou non, est déterminé par la valeur de l'option de base de données et il peut être modifié sans affecter l'application.
Remarque : Pour les applications qui sont conçues pour dépendre du comportement de blocage de l'isolement de lecture validée, les développeurs peuvent faire en sorte qu'elles fonctionnent avec les deux modes d'isolement de lecture validée. Sinon, il est important de noter que l'option de base de données READ_COMMITTED_SNAPSHOT reste OFF. - L'isolement de capture instantanée est vulnérable pour mettre à jour les conflits qui ne s'appliquent pas à l'isolement de lecture validée en utilisant le versioning de ligne. Lorsqu'une transaction s'exécutant sous l'isolement de capture instantanée lit des données qui sont ensuite modifiées par une autre transaction, une mise à jour du fait de la transaction de capture instantanée sur les mêmes données provoque un conflit de mise à jour et la transaction se termine et est restaurée. Cela n'est pas un problème avec l'isolement de lecture validée utilisant le versioning de ligne.
Quand utiliser l'isolement de lecture validée avec le versioning de ligne
L'isolement de lecture validée avec le versioning de ligne fournit une cohérence de lecture au niveau de l'instruction. Lors de l'exécution de chaque instruction de la transaction, une nouvelle capture des données est effectuée et reste cohérente pour chaque instruction, jusqu'à la fin de l'exécution de l'instruction. Activez l'isolement de lecture validée avec le versioning de ligne lorsque :
- Le nombre de blocage de lecture/écriture est tellement important que les avantages apportés par l'accès concurentiel compensent largement la surcharge causée par la création et la gestion de version de lignes.
- Une application nécessite une précision absolue pour des agrégations ou des requêtes à exécution longue où les valeurs de données doivent être cohérentes au moment précis où une requête démarre.
Quand utiliser l'isolement de capture instantanée
L'isolement de capture instantanée procure la cohérence de lecture au niveau de la transaction. Une capture instantanée des données est effectuée au démarrage de la transaction de capture instantanée et elle demeure cohérente pendant toute la transaction. Utilisez l'isolement de capture instantanée dans les cas suivants :
- Le contrôle d'accès concurrentiel optimiste est souhaité.
- Il est peu probable qu'une transaction doive être restaurée à cause d'un conflit de mise à jour.
- Une application doit produire des rapports en fonction de requêtes à plusieurs instructions et à exécution longue qui doivent avoir une cohérence dans le temps. L'isolement de capture instantanée procure l'avantage des lectures répétées (consultez Effet des accès concurrentiels) sans utiliser de verrous partagés. La capture instantanée de base de données peut offrir une fonctionnalité similaire, mais à mettre en œuvre manuellement. L'isolement de capture instantanée fournit automatiquement les informations les plus récentes de la base de données pour chaque transaction d'isolement de capture instantanée.
Avantages des niveaux d'isolement selon le versioning de ligne
Les niveaux d'isolement qui utilisent le versioning de ligne procurent les avantages suivants :
- Les opérations de lecture récupèrent une capture instantanée cohérente de la base de données.
- Les instructions SELECT ne verrouillent pas les données au cours d'une opération de lecture (les lecteurs ne bloquent pas les enregistreurs et vice versa).
- Les instructions SELECT peuvent accéder à la dernière valeur validée de la ligne, tandis que les autres transactions mettent à jour la ligne sans être bloquées.
- Le nombre de blocages est réduit.
- Le nombre de verrous requis par une transaction est réduit, ce qui réduit aussi la charge du système nécessaire à la gestion des verrous.
- Il y a moins de promotions de verrous.
Coûts des niveaux d'isolement selon le versioning de ligne
Si vous décidez d'utiliser l'isolement à base de versions de ligne, il faut comparer l'avantage de la simultanéité réduisant les verrouillages par rapport à l'utilisation accrue de ressources nécessaires à la gestion et à la lecture des versions de ligne. Considérez les coûts suivants associés à l'activation des versions de ligne pour les niveaux d'isolement de capture instantanée et de lecture validée :
- Les performances de lecture risquent d'être affectées lorsque les versions nécessaires aux requêtes deviennent anciennes et qu'il faut analyser de longues chaînes de versions.
- Le versioning de ligne augmente l'utilisation des ressources lors de la modification de données quand les versions de ligne sont gérées dans tempdb.
- Lorsque l'option de base de données READ_COMMITTED_SNAPSHOT ou ALLOW_SNAPSHOT_ISOLATION est ON, les transactions de mise à jour et de suppression pour une base de données particulière doivent gérer les versions de ligne même s'il n'y a pas de transactions qui utilisent un niveau d'isolement selon le versioning de versions de ligne. La construction d'une capture instantanée de données cohérente grâce aux versions de ligne implique des ressources système (UC et mémoire) et produit éventuellement de l'activité E/S. Comme les versions d'enregistrement sont stockées dans tempdb, les performances sont meilleures et le nombre d'E/S émises est inférieur lorsque davantage de pages tempdb peuvent être stockées dans la mémoire pour le versioning de ligne.
Remarque : En général, l'insertion d'une ligne ne produit pas de version de ligne. Dans certaines conditions toutefois, la commande INSERT produit une version de ligne. Par exemple, si vous insérez une ligne dans une table avec un index lorsqu'une version de ligne précédemment supprimée (enregistrement de type Ghost) n'a pas été tronquée, la commande INSERT produit une version de ligne. - tempdb doit avoir suffisamment d'espace disque pour la banque des versions. S'il existe des transactions à exécution longue, toutes les versions produites par les transactions de mise à jour pendant ce temps doivent être conservées dans tempdb. Si tempdb n'a plus assez de place, les opérations de mise à jour n'échouent pas, mais les opérations de lecture utilisant le versioning de ligne risquent d'échouer.
- Les informations de versioning de ligne requièrent 14 octets en plus dans la ligne de la base de données.
- Les performances de mise à jour peuvent être ralenties en raison des tâches de gestion des versions de ligne. Dans des charges de travail OLTP typiques, chaque mise à jour modifie juste quelques lignes dans une base de données. Dans ces systèmes, les performances des mises à jour dans une base de données où les options sont ON peuvent être seulement de quelques points de pourcentage moins élevées que dans des bases de données où les deux options sont OFF. L'impact sur les performances des mises à jour avec gestion des versions peut être plus important lorsque de plus grandes quantités de données sont modifiées pendant les mises à jour.
- Les lecteurs de données savent gérer les inconvénients du passage par la liste de liens des versions. Plus la capture instantanée est ancienne, plus l'accès est lent pour y accéder dans une transaction d'isolement de capture instantanée.
- Il faut peut-être restaurer certaines transactions de mise à jour utilisant l'isolement de capture instantanée à cause de la détection obligatoire de conflits des opérations de mise à jour. Les transactions qui s'exécutent dans le cadre d'un isolement de lecture validée avec le versioning de ligne ne produisent pas de conflits de mise à jour.
Les transactions utilisant le versioning de ligne ont d'autres limitations. Pour plus d'informations, consultez Utilisation de niveaux d'isolement basés sur la gestion de la version des lignes.
Systèmes qui tirent profit des niveaux d'isolement selon le versioning de ligne
Les scénarios qui tirent profit des niveaux d'isolement selon le versioning de ligne sont entre autres :
- les systèmes dans lesquels les rapports en lecture seule et les requêtes appropriées s'exécutent en parallèle avec une application qui met à jour les données ;
- la migration d'application vers Microsoft Moteur de base de données SQL Server à partir d'autres systèmes de bases de données relationnelles prenant en charge des niveaux d'isolement similaires ;
- les systèmes dans lesquels l'obtention d'agrégats cohérents, par exemple AVG, COUNT et SUM, ou la réalisation d'intersections d'index et de jointures d'index nécessiteraient un niveau d'isolement strict (comme des lectures pouvant être répétées ou sérialisées) ;
- les systèmes subissant un nombre élevé de blocages à cause d'une contention de lecture/écriture.
Voir aussi
Concepts
Présentation des niveaux d'isolement basés sur le versioning de ligne
Utilisation de niveaux d'isolement basés sur la gestion de la version des lignes
Utilisation de la ressource de versioning de ligne
Activation des niveaux d'isolement selon le versioning de ligne
Niveaux d'isolement du moteur de base de données