Depuración de una dura LINQ a SQL Tiempo de espera

Question

estoy recibiendo un error de tiempo de espera al intentar ejecutar una consulta LINQ (-to-SQL)

System.Data.SqlClient.SqlException: Tiempo de espera agotado. El período de tiempo de espera transcurrido antes de la finalización de la operación o el servidor no responde.

Ahora bien, esto es no sólo un caso de una consulta lenta:

• corro el equivalente SQL en SQL Server Management Studio y se completa rápidamente (2 segundos)
• estoy estableciendo mi CommandTimeout en 2 minutos.
• Cuando ejecuto la misma consulta en una prueba unitaria, se completa de manera exitosa y rápida. Es decir: solo recibo este tiempo de espera cuando ejecuto esta consulta junto con otras consultas. El tiempo de espera siempre ocurre en la misma llamada.

El último elemento me hizo pensar que estoy atrapando un punto muerto en el lado de la base de datos: la consulta está bloqueada por un bloqueo y el tiempo de espera expira, matando la conexión estancada.

El problema con esta idea es que estoy solo haciendo selecciones en el DataContext que está causando problemas. (Tengo inserciones que ocurren en una base de datos/DataContexts diferente). Tampoco tengo transacciones explícitas. Esto me hace tropezar un poco: el comportamiento de la consulta se ve exactamente como un punto muerto, pero nunca he tenido un punto muerto que no haya sido causado por algún tipo de problema de aislamiento de transacción, y ese no es el caso aquí (a primera vista de todos modos).

Estoy buscando consejos sobre cómo solucionar este problema. ¿Qué tipo de cosas debería considerar para determinar la causa de este problema?

EDITAR

Algunas notas que pueden ser útiles:

• estoy consulta contra una vista que hace referencia:
  • Otros puntos de vista en la misma base de datos
  • sinónimos que apuntan a tablas en otra base de datos a través de un servidor vinculado.
• Este punto de vista está utilizando union a unirse a los resultados de varias consultas juntos

Epílogo

terminé de arreglar el problema central de reelaboración de mi consulta. El original llamaba algunas tablas más de una vez (a través de diferentes vistas). La versión modificada pasó por alto todo esto y los tiempos de espera desaparecieron.

Answer 1

ejecute el código de nuevo desde la aplicación, mientras se está a la espera (durante 2 minutos ??) ejecutar esto en una ventana de consulta:

;with Blockers AS 
(SELECT 
    r.session_id AS spid 
     ,r.cpu_time,r.reads,r.writes,r.logical_reads 
     ,r.blocking_session_id AS BlockingSPID 
     ,LEFT(OBJECT_NAME(st.objectid, st.dbid),50) AS ShortObjectName 
     ,LEFT(DB_NAME(r.database_id),50) AS DatabaseName 
     ,s.program_name 
     ,s.login_name 
     ,OBJECT_NAME(st.objectid, st.dbid) AS ObjectName 
     ,SUBSTRING(st.text, (r.statement_start_offset/2)+1,((CASE r.statement_end_offset 
                    WHEN -1 THEN DATALENGTH(st.text) 
                    ELSE r.statement_end_offset 
                   END - r.statement_start_offset 
                  )/2 
                  ) + 1 
        ) AS SQLText 
    FROM sys.dm_exec_requests       r 
     JOIN sys.dm_exec_sessions      s ON r.session_id = s.session_id 
     CROSS APPLY sys.dm_exec_sql_text (sql_handle) st 
    --WHERE r.session_id > 50 
) 
SELECT Blockers.* FROM Blockers 

le mostrará todos los bloques en el momento de la carrera .

Answer 2

¿Está seguro de que los recursos no recogidos no consumen el conjunto de conexiones?

Pruebe envolviendo su SqlDataContext en un bloque en uso y vea si el problema persiste.