En Linq-to-SQL, ¿debo usar el nolock para mejorar el rendimiento?

Question

Nuestro DBA nos acudió con información que nuestras consultas LINQ están creando muchas miles de cerraduras en la base de datos. Un desarrollador en nuestro equipo desenterró esta publicación Hanselman como una posible solución a nuestro problema:

http://www.hanselman.com/blog/gettinglinqtosqlandlinqtoentitiusenolock.aspx < / p>

Scott proporciona 3 maneras en Linq para configurar el nolock. 1) Transactionscope (preferido), 2) sprocs, 3) contexto.executecommand

Somos un sitio de noticias que se lee el 99%, el 1% escribe para que nuestro enfoque principal está en la velocidad de recuperación. Es nolock una buena estrategia para todas nuestras consultas Linq-to-SQL?

Lo que estoy tratando de entender es por qué usando el nolock es o no es una buena idea. Debe haber muchas personas con nuestros mismos objetivos: muchas lecturas rápidas, poca o ninguna actualización. Si Nolock es la respuesta obvia, ¿por qué no es el valor predeterminado? ¿Por qué no puedo hacerlo predeterminado en el contexto, en lugar de tener que configurarlo en cada llamada de datos?

es nolock realmente la mejor opción para las muchas lecturas rápidas, ¡pocos actualizaciones del sitio?

Actualización: en SQL Server 2005 y superior, ¿es mejor el aislamiento de la instantánea que el nolock? Acabo de encontrar esto http://msdn.microsoft.com/en-us/library/ms179599.aspx

que cubre lee instantánea comprometida . Esto evita el bloque de escritura, pero no devuelve datos sucios? ¿Debería usar esto el 90% del tiempo sobre el nolock?

actualización 2: lo que me molesta es seco

La parte que más le está molestando es que para implementar un patrón de no bloqueo o instantánea, tengo que cambiarlo en cada método de consulta LINQ-A-SQL (excepto aquellos que se utilizan en las actualizaciones). Esto huele a una gran violación de seco.

Answer 1

Worth noting: READ COMMITTED SNAPSHOT is (or at least was 2+ years ago) good enough for the site you're using.