¿Por qué READ_COMMITTED_SNAPSHOT no está activado de manera predeterminada?

Question

Pregunta simple?

¿Por qué READ_COMMITTED_SNAPSHOT no está activado de manera predeterminada?

¿Adivino la compatibilidad hacia atrás, el rendimiento o ambos?

[Editar] Tenga en cuenta que estoy interesado en el efecto relacionado con el nivel de aislamiento READ_COMMITTED y no en el nivel de aislamiento de instantáneas.

¿Por qué sería esto un cambio radical, ya que tiene menos bloqueos y aún no lee las filas no confirmadas?

Answer 1

Ambos. Mayormente compatibilidad.

Al activar la instantánea de forma predeterminada, se rompería la gran mayoría de las aplicaciones que esperan el comportamiento anterior de bloqueo. Instantánea hace uso pesado de de tempdb para la tienda de versiones y su impacto en el rendimiento es bastante mensurable.

Answer 2

Cambia la estrategia de bloqueo predeterminada de cómo la familia Sybase/SQL Server funcionó para siempre. Rompe todas mis aplicaciones, todas las aplicaciones que conozco en mi tienda y corrompe una gran cantidad de datos importantes.

Lea Wikipedia articlecompletamente: ¿Desea que el código detrás de su aplicación de banca utilice este modelo de aislamiento?

En general, por lo tanto, el aislamiento de instantáneas pone algunos de los problemas de mantener restricciones no triviales en el usuario, que pueden no apreciar cualquiera de los peligros potenciales o los soluciones posibles. La ventaja de esta transferencia es un mejor rendimiento.

Es un compromiso como la mayoría de los diseños de bases de datos. En mi caso, puedo lidiar con las esperas de bloqueo/interbloqueos (poco frecuentes) como un precio para una integridad de datos más sencilla y más "lista para usar". Todavía me he encontrado con un problema o problema donde veo el aislamiento de instantáneas como una solución.

Answer 3

Volviendo instantánea por defecto se rompería la gran mayoría de aplicaciones

No está claro para mí si se romperá la "inmensa mayoría" de las aplicaciones. O bien, si rompe muchas aplicaciones de maneras difíciles de identificar y/o difíciles de solucionar. La documentación de SQL Server indica que READ COMMITTED y READ COMMITTED SNAPSHOT satisfacen la definición ANSI de READ COMMITTED. (Expresado aquí: http://msdn.microsoft.com/en-us/library/ms189122.aspx) Por lo tanto, siempre que su código no dependa de nada más allá del comportamiento literal requerido por ANSI, en teoría, estará bien.

Una complicación es que la especificación ANSI no captura todo lo que la gente comúnmente piensa que cosas como lectura sucia, lectura difusa/no repetible, etc. significan en la práctica. Y, existen anomalías (permitidas por las definiciones de ANSI) que pueden ocurrir en READ COMMITTED SNAPSHOT que no pueden ocurrir en READ COMMITTED. Para un ejemplo, vea http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/.

Ver también http://social.msdn.microsoft.com/Forums/en-US/sqldatabaseengine/thread/d1b3d46e-2642-4bc7-a68a-0e4b8da1ca1b.

Para obtener información detallada sobre las diferencias entre los niveles de aislamiento, comience por http://www.cs.umb.edu/cs734/CritiqueANSI_Iso.pdf (READ_COMMITTED_SNAPSHOT no estaba disponible cuando se escribió este documento, pero los otros niveles están cubiertos por él).