La base de données SQL Server écrit-elle plus lentement avec l'isolement de capture instantanée?

8

J'ai de nombreux blocages dans mon système.

Je voudrais utiliser Snapshot Isolation pour les corriger, mais mon DBA a des réserves à ce sujet.

L'une de ses préoccupations est que Snapshot Isolation ralentit les écritures. Cela est dû au fait qu'il doit écrire dans le cache, puis dans TempDb (version en ligne), puis il peut retourner à l'appelant.

Une écriture "normale" peut simplement écrire dans le cache puis être effectuée.

Est-ce ainsi que fonctionne le versioning des lignes? Ou est-ce plus complexe que ça? Est-ce que cela les fait en parallèle?

Ou les écritures sont-elles plus lentes avec Snapshot Isolation?

— Vaccano
source

2

Un problème à surveiller lorsque vous activez l'isolement de capture instantanée: la taille de votre ligne augmentera de 14 octets. Assurez-vous que vous avez prévu cette augmentation de capacité et les éventuelles divisions de page qui en résultent.

— StanleyJohns

14

c'est parce qu'il doit écrire dans le cache, puis dans TempDb (version en ligne), puis il peut retourner à l'appelant.

Non, c'est incorrect. Cela implique en quelque sorte que les écritures en présence de versioning ont une latence plus élevée car chaque écriture doit toucher le disque (pour tempdb), ce qui n'est pas vrai. L'écriture dans tempdb est également une écriture dans «cache». La seule «attente» se produit au moment de COMMIT lorsque le journal doit être durci. Est-il vrai que la version du journal de la base de données et du journal tempdb doit être renforcée, mais cela n'implique pas nécessairement une latence plus élevée (l'IO doit être parallèle sur différents chemins de stockage, le tempdb est stocké sur un lecteur distinct de votre LDF très utilisé, droite?). Pour une explication complète, lisez Comment ça marche: Présentation d'E / S SQL Server de Bob Dorr J'espère vraiment que votre DBA comprend mieux que vous ne le transmettez ici.

Comme je l'ai mentionné dans votre autre article: l'instantané n'a aucun coût pour les INSERTS et le coût des mises à jour et des suppressions peut facilement être atténué. L'utilisation des ressources de gestion des versions de lignes explique les compromis. En ce moment, vous devriez probablement tester avec une charge de travail réaliste, qui est le seul moyen d'évaluer correctement l'impact que vous ressentiriez.

— Remus Rusanu
source

4

BTW considère ceci: avez-vous, ou votre DBA, déjà utilisé des déclencheurs au cours des 7 dernières années? Depuis SQL 2005, les déclencheurs sont implémentés à l'aide d'instantanés en arrière-plan. Il en va de même si vous avez déjà utilisé la reconstruction d'index en ligne ou MARS . Que diriez-vous si vous vérifiez en ce moment sys.dm_db_file_space_usagesur votre serveur de production. Si version_store_reserved_page_countest différent de zéro, vous utilisez déjà le magasin de versions .

— Remus Rusanu

Je ne pense pas que le journal de tempdb doive être durci, car le rétablissement n'est jamais exécuté sur tempdb. Les frais généraux sont donc encore plus bas.

— usr

0

Je crois qu'il y a d'autres problèmes dans l'application si vous obtenez des blocages. L'isolement de cliché aide généralement à réduire les verrous d'attente, mais la racine des blocages est généralement des méthodes d'accès différentes dans l'application qui devraient être évitées en respectant un modèle cohérent. Les discussions sur les blocages sont compliquées et de nombreuses ressources leur sont consacrées.

Votre administrateur de base de données a raison de s'inquiéter de la modification du niveau d'isolement en instantané, car cela augmente la charge sur tempDB. Je recommande d'aller à l'isolement des instantanés en général, mais je pense que ce n'est qu'un élément pour résoudre vos blocages. Vous pouvez vous retrouver avec des écritures sales, où une transaction met à jour la ligne A puis B, et une autre transaction met à jour la ligne B puis A.

— Robert-Ryan.
source