Choix des niveaux d'isolement selon 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.

  Notes

  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 fantôme) 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

Référence

Concepts