¿Usando NOLOCK Hint en EF4?

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 estaba aquí y animo a todos los interesados ​​en este tema a leer este hilo.

Gracias.

NOLOCK = “LEER NO COMPROMETIDO” = lecturas sucias

Supongo que MS sabe por qué eligieron el nivel de aislamiento predeterminado como “LEÍDO COMPROMETIDO”

NOLOCK, de hecho, cualquier pista, debe usarse con mucha prudencia: no de forma predeterminada.

Tu DBA es un muppet. Vea esto (SO): ¿Qué puede pasar como resultado de usar (nolock) en cada SELECT en SQL Sever? . Si trabaja en un banco o en cualquier institución donde tenga una cuenta, avíseme para poder cerrarlo.

Soy desarrollador de un equipo de herramientas en la organización de SQL en Microsoft. No estoy de ninguna manera autorizado para hacer una statement oficial, y estoy seguro de que hay personas en SO que saben más sobre estas cosas que yo. Sin embargo, ofreceré una regla práctica 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 que hacerlo. 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 eliges usar NOLOCK, he creado una solución de blog en C # usando métodos de extensión, para que puedas cambiar fácilmente una consulta LINQ y usar sugerencias de NOLOCK. Si puede adaptar esto a EF4, publique su adaptación.

EF4 actualmente no tiene una forma integrada de hacerlo SI EF4 está generando todas sus consultas.

Hay 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 llevar 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 los sitios de 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 TODOS los seleccionados. 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 fueron ÚNICAMENTE selectas (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 sobre 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.

Información sobre niveles de aislamiento

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 no es un hack y es absolutamente necesario para el desempeño en ciertas situaciones.

Nuestra plataforma recibe mucho tráfico a través de nuestro sitio web, API y fonts 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 encuentra que necesita hacer que los datos estén disponibles a través de EF y necesita NOLOCKs , siempre puede crear vistas con las sugerencias de NOLOCK incluidas y exponer la vista a EF en lugar de a 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 mucha gente comete 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.

Aunque este sería un PITA importante para hacer, siempre puede soltar su SQL en un procedimiento almacenado y obtener la funcionalidad que necesita (o se lo fuerza). ¡Definitivamente es un hack!

Sé que esta no es una respuesta a su pregunta, pero solo quería contarle esto.

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 progtwigrla de la manera que a él le gustaría.

La única forma de estar seguro, sin embargo, 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.