Opciones para configurar la sugerencia NOLOCK en consultas de conjunto de datos

Algún contexto:
al principio escribimos informes simplemente "directos", sin ninguna pista de bloqueo en las consultas. Con los informes más grandes, esto a veces podría causar problemas de bloqueo. Al principio solucionamos esto usando la WITH (NOLOCK)sugerencia para tablas en la consulta.

Debido a que (a) es bastante molesto, y (b) que es fácil olvidar el toque de una de las mesas, se pasó a un segundo ajuste de enfoque TRANSACTION ISOLATION LEVELa READ UNCOMMITTED(que está bien) en la parte superior de consulta de cada conjunto de datos.

Como puede suponer, aún es fácil olvidar la pista para uno de los conjuntos de datos. Entonces esto lleva a la pregunta:

Pregunta: ¿Cuáles son las opciones para enviar NOLOCKsugerencias junto con consultas de informes?

PD. Me doy cuenta de que esto es, en cierta medida, un problema XY (con muchas de mis otras opciones para X, como optimizar la consulta, no hacer informes en la base de datos operativa, etc.), pero de todos modos traté de hacer una pregunta válida sobre sí misma. .

Opciones:
Estas son las opciones mencionadas anteriormente, con opciones adicionales sobre las que tengo curiosidad por saber si funcionarían:

1. Establecer WITH (NOLOCK)pista para cada mesa. (molesto, muy fácil de olvidar)
2. Establezca el nivel de aislamiento READ UNCOMMITTEDpara toda la consulta. (sigue siendo fácil de olvidar)
3. ¿Es posible especificar esto a nivel de informe ? Por ejemplo, asegúrese de que todas las consultas del conjunto de datos para un informe se ejecuten sin bloqueo.
4. ¿Es posible especificar esto en algún otro nivel de SSRS ? Por ejemplo, ¿puede configurar esto para una determinada carpeta de informes o mediante una extensión?
5. ¿Es posible especificar esto en la fuente de datos / nivel de cadena de conexión ? Por ejemplo, ¿todos los informes relevantes utilizan una determinada "fuente de datos sin bloqueo"?
6. Relacionado con la opción anterior: ¿tal vez es posible especificar una pista de bloqueo predeterminada para un "usuario no sql-lock" específico (el que se usa en la conexión)?
7. ???

¿Qué opciones son viables? ¿Hay opciones que he perdido?

Respuestas Rápidas:

1. Funciona, como habrás notado.
2. Funciona, como habrás notado.
3. Esto no parece funcionar. No vi una opción por adelantado y cada vez que se hace esa pregunta, la respuesta siempre vuelve a establecer el nivel de aislamiento en el procedimiento almacenado .
4. No lo creo. SSRS se encuentra en una capa de abstracción más alta que el motor de base de datos, por lo que, en cierto sentido, no le importa cuál sea el nivel de aislamiento; después de todo, puede usar soluciones que no sean RDBMS en sus informes.
5. Esto no funciona. No puede establecer el nivel de aislamiento en la cadena de conexión .
6. Esto podria funcionar. Puede crear un desencadenador de inicio de sesión .

Hay algunas opciones que son viables si los informes están optimizados y siguen causando problemas:

1. Use Always On si tiene SQL 2012. Entonces podría tener una réplica de solo lectura que sus informes SSRS podrían usar.
2. Utilice la replicación: instantánea si no necesita en tiempo real, y transaccional si necesita que esté cerca del tiempo real.
3. Si no tiene el presupuesto para Always On o la paciencia para lidiar con la replicación, realice la replicación a bajo costo: cree un esquema amigable para los informes (es decir, desnormalice las tablas y póngalas en un formato que facilite la ejecución de informes ) y use SSIS para alimentar ese esquema de informe. Esto funciona mejor si los usuarios finales pueden vivir con datos "más antiguos" (por ejemplo, actualizando cada hora o cada 5 minutos). La desventaja es que diseñará el modelo de datos dos veces: una para el modelo OLTP y otra para el modelo de pseudoalmacenamiento. Lo bueno es que si alguna vez te mueves en dirección a un almacén de datos centralizado, este es un ejercicio muy útil.

¿Ha considerado el READ_COMMITTED_SNAPSHOTversionado de filas para la base de datos?

Kim Tripp tiene un buen artículo al respecto en http://msdn.microsoft.com/en-us/library/ms345124%28v=sql.90%29.aspx

READ_COMMITTED_SNAPSHOTpermite una mejor funcionalidad WITH (NOLOCK)que porque proporciona una consistencia absoluta en un punto en el tiempo para agregaciones o consultas de larga duración con un mayor rendimiento debido a la contención de bloqueo reducida.