SQL Server - quel niveau d'isolement pour les instructions select non bloquantes?

J'ai une transaction de longue durée (appelée, par exemple, T1) qui effectue des suppressions, des mises à jour et des insertions sur une table dans SQL Server 2008 R2. Dans le même temps, un autre processus exécute périodiquement les instructions select de cette table.

Sous les paramètres d'isolement par défaut (LIRE COMMIS, je pense?), T1 bloque l'exécution de toutes les instructions Select jusqu'à ce que la transaction soit validée ou annulée.

Ce que j'aimerais voir, c'est que les instructions select fonctionnent sur des données cohérentes même lorsque la transaction est en cours. Je crois que l'isolement INSTANTANÉ peut aider, mais je ne sais pas si je vais dans la bonne direction. Serait-ce le meilleur niveau d'isolement pour cette application?

Deuxièmement, je n'ai aucun contrôle sur le processus qui appelle les instructions select, mais j'ai le contrôle sur l'application .NET qui appelle T1. Des modifications du niveau d'isolement seraient-elles nécessaires à la fois sur les instructions select et sur T1, ou suffirait-il de marquer uniquement T1 comme ayant un niveau d'isolement différent?

Dans un monde idéal, vous auriez deux choix: INSTANTANÉ et INSTANTANÉ LECTURE COMMIS (RCSI). Assurez-vous de comprendre les principes de base des niveaux d'isolement des transactions avant de décider lequel convient à votre charge de travail. Soyez particulièrement attentif aux différents résultats que vous pouvez constater lors du passage à RCSI.

Cela semble que ce n'est pas un monde idéal car vous n'avez aucun contrôle sur l'application qui génère les instructions select. Dans ce cas, votre seule option est d'activer RCSI pour la base de données en question de sorte que les sélections utilisent automatiquement RCSI au lieu de LIRE COMMIS.

Correct, utilisez l'isolement SNAPSHOT pour obtenir des données cohérentes et validées avant le début de la transaction.

L'isolement READ UNCOMMITTED (alias NOLOCK hint) lira les données sales et incohérentes

Lorsque vous activez l'isolement SNAPSHOT, il prend effet pour tous les SELECT à l'avenir. Vous exécutez ALTER DATABASEavec READ_COMMITTED_SNAPSHOT dans ce cas

Modifier: lien ajouté + citation de ALTER DATABASE (mon gras)

Active l'option Instantané validé en lecture au niveau de la base de données. Lorsqu'il est activé, les instructions DML commencent à générer des versions de ligne même lorsqu'aucune transaction n'utilise l'isolement de capture instantanée. Une fois cette option activée, les transactions spécifiant le niveau d'isolement validé en lecture utilisent le versionnement des lignes au lieu du verrouillage. Lorsqu'une transaction s'exécute au niveau d'isolement validé en lecture, toutes les instructions voient un instantané des données telles qu'elles existent au début de l'instruction.

Et de l' utilisation de l'isolement de l'instantané (mon gras)

L'option de base de données READ_COMMITTED_SNAPSHOT détermine le comportement du niveau d'isolement READ COMMITTED par défaut lorsque l'isolement de capture instantanée est activé dans une base de données. Si vous ne spécifiez pas explicitement READ_COMMITTED_SNAPSHOT ON, READ COMMITTED est appliqué à toutes les transactions implicites. Cela produit le même comportement que la désactivation de READ_COMMITTED_SNAPSHOT (valeur par défaut). Lorsque READ_COMMITTED_SNAPSHOT OFF est en vigueur, le moteur de base de données utilise des verrous partagés pour appliquer le niveau d'isolement par défaut. Si vous définissez l'option de base de données READ_COMMITTED_SNAPSHOT sur ON, le moteur de base de données utilise la version de ligne et l'isolement de capture instantanée par défaut, au lieu d'utiliser des verrous pour protéger les données.

Donc oui.

L'activation de RCSI permet aux lectures d'obtenir des données cohérentes et de ne pas être bloquées par les écrivains qui continueront à utiliser Read Committed

Je vous suggère de lire la question suivante et ses réponses: Problèmes de verrouillage de la base de données? .

Trouver le bon niveau d'isolement à utiliser au niveau de la base de données est la chose la plus rapide que vous pouvez faire dès maintenant pour vous aider à résoudre ce problème, car il est difficile maintenant de changer toutes les applications qui touchent la base de données et de changer leur code. Puisque vous avez dit "Je n'ai aucun contrôle sur le processus qui appelle les instructions select", la réponse la plus rapide serait de basculer la base de données sur le niveau d'isolement Read Committed Snapshot, de sorte que vous ne touchiez pas aux requêtes de lecture. Sinon, vous devrez utiliser le niveau d'isolement Snapshot pour les sessions qui lisent des données lors de vos grosses transactions.

Plus de détails ici sur le choix du bon: Choix des niveaux d'isolement basés sur le versionnement des lignes .