¿Cómo utilizar NOLOCK Hint en EF4?

Question

Estamos evaluando EF4 y mi DBA dice que debemos usar la sugerencia NOLOCK en todas nuestras declaraciones SELECT. Así que estoy buscando cómo hacer que esto suceda cuando use EF4.

He leído las diferentes ideas sobre cómo hacer que esto suceda en EF4, pero todo parece ser una alternativa y no sancionado por Microsoft o EF4. ¿Cuál es la respuesta de "Microsoft oficial" a alguien que quiere que sus declaraciones SELECT incluyan la sugerencia de NOLOCK al usar LINQ-to-SQL/LINQ-to-Entities y EF4?

Por cierto, la mejor información absoluta que he encontrado es right here y animo a todos los interesados ​​en este tema a leer este hilo.

Gracias.

Answer 1

Sé que esto no es una respuesta a su pregunta, pero yo sólo quería tirar esto en.

Me parece que esto es (al menos parcialmente) el trabajo del DBA. Está bien decir que una aplicación debe comportarse de cierta manera, y puedes y debes intentar programarla de la manera que a él le gustaría.

La única manera de estar seguro es que el DBA trabaje en la aplicación con usted y construya la superficie de la base de datos que le gustaría presentar a la aplicación. Si quiere que se consulten las tablas críticas como READ UNCOMMITTED, debe ayudar a proporcionar un conjunto de procedimientos almacenados con el nivel correcto de acceso y aislamiento.

Confiar en el código de la aplicación para construir correctamente cada consulta ad-hoc no es un enfoque escalable.

Answer 2

NOLOCK = "READ" = lecturas sucias

Me asumir MS sabe por qué eligieron el nivel de aislamiento por defecto como "READ COMMITTED"

NOLOCK, de hecho, cualquier indicio, se debe utilizar muy juiciosamente: no por defecto.

Su DBA es un muppet. Vea esto (SO): What can happen as a result of using (nolock) on every SELECT in SQL Sever?. Si trabaja en un banco o en cualquier institución donde tenga una cuenta, avíseme para poder cerrarlo.

Answer 3

Soy un desarrollador de un equipo de herramientas en la organización de SQL en Microsoft. No estoy de ninguna manera autorizado para hacer una declaración oficial, y estoy seguro de que hay personas en SO que saben más sobre estas cosas que yo. Sin embargo, ofreceré una regla empírica amistosa, junto con el tema "La optimización prematura es la raíz de todo mal":

No use NOLOCK (o cualquier otra sugerencia de consulta), hasta que tenga a. Si tiene una instrucción select que tiene un plan de consulta decente, y funciona bien cuando hay muy poca carga en el sistema, pero luego se ralentiza cuando otras consultas acceden a la misma tabla, intente agregar algunas sugerencias de NOLOCK. Pero siempre entiende que cuando lo haces, corres el riesgo de obtener datos inconsistentes. Si está escribiendo alguna aplicación de misión crítica que hace banca en línea o controla una aeronave, esto puede ser inaceptable. Sin embargo, para muchas aplicaciones, la aceleración de rendimiento vale la pena el riesgo. Sin embargo, evalúe caso por caso. No los uses de cualquier manera en cualquier lugar.

Si elige usar NOLOCK, tengo blogged a solution en C# utilizando métodos de extensión, de modo que pueda cambiar fácilmente una consulta LINQ para usar sugerencias de NOLOCK. Si puede adaptar esto a EF4, publique su adaptación.

Answer 4

EF4 actualmente no tiene una forma integrada de hacerlo IF ef4 genera todas sus consultas.

Existen varias formas de evitar esto, como el uso de procedimientos almacenados o un modelo de consulta en línea más extenso; sin embargo, esto puede consumir mucho tiempo, por decir lo menos.

Creo (y no hablo de Microsoft en esto) que el almacenamiento en caché es la solución prevista de Microsoft para aligerar la carga en el servidor en sitios EF4. Habiendo leído sin compromiso (o nolock) incorporado en un marco crearía problemas impredecibles para el comportamiento esperado de EF4 cuando se ejecutan 2 contextos al mismo tiempo. Eso no significa que su situación necesite ese nivel de concurrencia.

Parece que le pidieron nolock en TODAS las selecciones. Si bien estoy de acuerdo con un póster anterior en que esto puede ser peligroso si tiene CUALQUIER transacción que deba ser una transacción, no estoy de acuerdo en que automáticamente haga del DBA un muppet. Es posible que solo esté ejecutando un CMS que es totalmente genial para lecturas sucias. Puede cambiar el NIVEL DE AISLAMIENTO en toda su base de datos que puede tener el mismo efecto.

El DBA puede haber recomendado nolock para operaciones que SÓLO fueron seleccionadas (lo cual está bien, especialmente si hay un ORM mal interpretado y haciendo algunos volcados de datos dudosos). Lo más gracioso de ese comentario de muppet es que Stack Overflow en sí mismo ejecuta el servidor SQL en un modo de LEER NO COMPROMETIDO. ¿Adivina que necesita encontrar otro lugar para obtener respuestas a sus problemas, entonces?

Hable con su DBA acerca de la posibilidad de configurar esto en una base de datos o considere una estrategia de almacenamiento en caché si solo la necesita en algunos lugares. Después de todo, la web no tiene estado, por lo que la simultaneidad a menudo puede ser una ilusión, a menos que usted lo aborde directamente.

Info about isolation levels

Answer 5

Aunque esto sería un importante PITA hacer, siempre se puede caer el SQL en un procedimiento almacenado y obtener la funcionalidad que necesita (o son forzadas a). ¡Definitivamente es un hack!

Answer 6

Después de haber trabajado con EF4 durante más de un año, ofreceré que el uso de procedimientos almacenados para tareas específicas es no es un truco y es absolutamente necesario para el rendimiento en ciertas situaciones.

Nuestra plataforma obtiene mucho de tráfico a través de nuestro sitio web, API y fuentes de datos ETL. Usamos EF principalmente en nuestro lado web, pero también para algunos procesos de back-end. A veces EF hace un gran trabajo con la generación de consultas, a veces es terrible. Debe mirar las consultas que se están generando, cargarlas en el analizador de consultas y decidir si es mejor escribir la operación de otra manera (procedimiento almacenado, etc.).

Si usted encuentra que usted necesita para hacer que los datos disponibles a través de EF y necesita NOLOCKs, siempre se puede crear puntos de vista con los consejos NOLOCK incluido, y exponer a la vista a EF en lugar de la tabla subyacente. Lo mismo se puede hacer con los procedimientos almacenados. Es probable que estos métodos sean un poco más fáciles cuando usa el enfoque Code First.

Pero creo que un error que muchas personas cometen con EF es creer que el modelo de objetos EF tiene que mapearse directamente en el modelo físico (tabla) en la base de datos. No es así y aquí es donde su DBA entra en juego. Permita que diseñe su modelo físico y trabaje en conjunto para abstraer su modelo de datos lógicos que está mapeado a su modelo de objetos en EF.