Pourquoi READ_COMMITTED_SNAPSHOT n'est pas activé par défaut?

Question

Simple question?

Pourquoi READ_COMMITTED_SNAPSHOT n'est pas activé par défaut?

Je suppose que la rétrocompatibilité, la performance ou les deux?

[Éditer] Notez que je suis intéressé par l'effet relatif au niveau d'isolation READ_COMMITTED, et non par le niveau d'isolement de l'instantané.

Pourquoi cela constituerait-il une rupture, car il contient moins de verrous et ne lit toujours pas les lignes non validées?

Answer 1

Les deux. Principalement compatibilité.

Activer l'instantané par défaut casserait la grande majorité des applications qui attendent l'ancien comportement de blocage. Snapshot rend lourd l'utilisation de tempdb pour la version store et son impact sur les performances est assez mesurable.

Answer 2

Il modifie la stratégie de verrouillage par défaut de la façon dont la famille Sybase/SQL Server a fonctionné pour toujours. Il casserait toutes mes applications, toutes les applications que je connais dans mon magasin et corromprait beaucoup de données importantes.

Lire le Wikipedia articlecomplètement: voulez-vous que le code derrière votre application bancaire utilise ce modèle d'isolation?

En isolement général, donc, instantané met une partie du problème de maintenir des contraintes non négligeables sur l'utilisateur, qui peut ne pas apprécier ni les pièges potentiels ou les solutions possibles. L'avantage de ce transfert est une meilleure performance.

C'est un compromis comme la plupart des conceptions de base de données. Dans mon cas, je peux traiter les attentes/verrous bloquants (rares) comme prix pour une intégrité des données plus facile et plus «prête à l'emploi». Je n'ai pas encore rencontré un problème ou un problème où je vois l'isolement d'instantané comme une solution.

Answer 3

Mise snapshot par défaut briserait la grande majorité des applications

On ne sait pas si elle me brisera la « grande majorité » des applications. Ou, si cela va casser de nombreuses applications d'une manière difficile à identifier et/ou difficile à contourner. La documentation SQL Server indique que READ COMMITTED et READ COMMITTED SNAPSHOT tous les deux satisfont la définition ANSI de READ COMMITTED. (A déclaré ici: http://msdn.microsoft.com/en-us/library/ms189122.aspx) Donc, tant que votre code ne repose sur rien d'autre que le comportement littéral ANSI requis, en théorie, vous serez bien. Une complication est que la spécification ANSI ne capture pas tout ce que les gens pensent communément des choses comme la lecture sale, la lecture floue/non répétable, etc. dans la pratique. Et, il existe des anomalies (autorisées par les définitions ANSI) qui peuvent se produire sous READ COMMITTED SNAPSHOT qui ne peuvent pas se produire sous READ COMMITTED. Pour un exemple, voir http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/.

Voir aussi http://social.msdn.microsoft.com/Forums/en-US/sqldatabaseengine/thread/d1b3d46e-2642-4bc7-a68a-0e4b8da1ca1b.

Pour une information approfondie sur les différences entre les niveaux d'isolement, commencez par http://www.cs.umb.edu/cs734/CritiqueANSI_Iso.pdf (READ_COMMITTED_SNAPSHOT n'était pas là lorsque ce papier a été écrit, mais les autres niveaux sont couverts).