Para cualquiera que no sea ya un experto en implementaciones de bloqueo y bases de datos, este puede ser un tema sorprendentemente difícil para su mente.
Recomiendo leer esto series of posts on snapshot isolation por Hugo Kornelis (SQL Server MVP). Hasta ahora es el análisis más completo que he visto de consideraciones prácticas de al usar instantáneas.
resumir las principales cuestiones:
- Cuando una combinación particular de transacciones simultáneas haría posible que viola una restricción (UNIQUE, FOREIGN KEY, etc.), SQL Server caerá de nuevo a la manera antigua de hacer cosas. Esto es bueno para la confiabilidad, obviamente, pero no para el rendimiento. Las instantáneas no son una panacea, no reemplazan el buen diseño de bases de datos/consultas y la gestión inteligente de los bloqueos.
- Es posible que las instantáneas y los disparadores no funcionen bien juntos. Es especialmente peligroso si usa desencadenadores para proteger la integridad de los datos, pero incluso si no lo hace, casi todos sus desencadenantes tendrán que tomarse en cuenta.
Dependiendo de cómo escriba sus consultas, puede que ni siquiera necesite usar desencadenadores para terminar con unexpected or inconsistent results.
No sé si los costos son fijos o lineales, aunque definitivamente no son geométricos; Sí sé que es un dolor de cabeza un poco. A menudo se lo menciona como una opción de "olvídate del fuego y olvídate", pero la verdad es que no lo es, si no sabes lo que estás haciendo, puedes terminar rompiendo cambios (sobre los que probablemente no vas a descubrir hasta que sea demasiado tarde!).
Por supuesto, utilícelo si está seguro de que no causará ningún otro problema.Pero si alguno de sus lógicos no se preocupa por las lecturas sucias (y esto se aplica a más de la mitad de las consultas SELECT en muchos sistemas), obtendrá resultados mucho mejores con READ UNCOMMITTED (que implica más "experiencia" - tiene que piensa con mucho cuidado sobre lo que puede suceder y cuándo).
Actualización: En las alternativas a nivel de aplicación
El único que viene a la mente es el almacenamiento en caché. Algunos marcos de datos pueden hacer esto por usted (NHibernate, EF) y, en algunos casos, incluso podría tener un tercer nivel de almacenamiento en caché, como servicios web que almacenan los resultados basados en la entrada del mensaje, resultados que pueden basarse en varias consultas. Realmente no llamaría a esto una "alternativa", pero imagino que algún tipo de almacenamiento en caché sería efectivo en su caso si se trata de consultas de solo lectura y los datos subyacentes no cambian con frecuencia. La consideración del diseño es, por supuesto, la cantidad de datos que puede permitirse almacenar en caché en relación con la cantidad que necesita atender; si el sistema es masivamente concurrente, puede que no se escale.
Más allá de eso, personalmente no elegiría intentar implementar mi propio "nivel" transaccional a nivel de aplicación. Tal vez algunas personas lo hayan hecho, pero no creo que haya ninguna manera de que mi experiencia limitada pueda competir con cientos o miles de los diseñadores más brillantes que trabajan en un SGBD durante 20 años.
Esta es una gran respuesta. Hemos considerado READ UNCOMMITTED, pero estas consultas que estoy ejecutando con el aislamiento de instantáneas son de solo lectura y para "consumo humano", sin operaciones de escritura dentro de la misma transacción. Por lo tanto, prefiero la coherencia interna del conjunto de resultados y la ausencia de bloqueo sobre la moneda de datos. ¿Suena como un uso apropiado? ... Estoy leyendo tus enlaces también. –
Además, ¿hay alternativas a nivel de aplicación? Diferentes niveles de aislamiento dan resultados diferentes, pero un patrón de nivel de aplicación puede lograr los mismos beneficios utilizando solo el aislamiento LEÍDO COMPROMETIDO con instantáneas desactivadas. ¿O tal intento hecho en casa hará que el desempeño sea aún peor? –
En mi opinión, el aprendizaje READ UNCOMMITTED se debe utilizar SOLAMENTE en casos extremos. Si realmente construyes un sistema alrededor de READ UNCOMMITTED diviértete con una pesadilla, espero que mis datos personales no estén en tu sistema. Hay muchas razones para no usarlo. Puede dar resultados impredecibles fuera de las lecturas sucias. La única vez que lo uso es cuando tengo una gran transacción de datos de bombeo y quiero un recuento aproximado de cuántos registros han ingresado. Hago esto ad-hoc. Acceda a la lectura de cualquier gurú de SQL Server y vea qué piensan al respecto. – Kuberchaun