Las consultas SQL simples no finalizan [cerrado]

No sé cómo formular la pregunta porque todavía no sabemos mucho, pero me gustaría preguntar más temprano que tarde porque esto parece algo que no debe descuidarse.

Esta semana comenzamos a tener problemas con nuestro servidor de base de datos. Parece ser un problema de consistencia de datos y se manifiesta por tiempos de espera incluso en consultas muy simples y tablas pequeñas. "Solucionamos" el problema reiniciando el servidor a principios de esta semana y desapareció, pero ahora parece que está volviendo y esta vez en tablas más cruciales. Por ejemplo, acabo de investigar un poco y estoy viendo una consulta como esta:

SELECT * FROM table WHERE id = 1234

para una identificación particular. La tabla tiene más de 30 millones de filas. Pero parece que sucede solo para una pequeña fracción de los registros. Apuesto a que cuando reinicie el servidor o haga una copia de seguridad y restaure la base de datos en otro servidor, todo estará bien. Pero lo intentaré.

En este punto, estoy corriendo:

DBCC CHECKTABLE ('table', NOINDEX)

pero parece que va a correr para siempre. Cuando nos topamos con los problemas por primera vez, revisé la tabla ofensiva y estuvo bien. Esta nueva mesa es mucho más grande.

Alguna información técnica de fondo:

• SQL Server 2008 R2, Windows Server 2008 R2
• AWS / EC2, m2.2xlarge, 32 GB de RAM, 4 x 1TB RAID 0
• casi no hay disco IO, parece que la mayor parte de la base de datos está en la memoria
• tamaño total de base de datos: 100 GB

Los volúmenes ELB son "nuevos". Los creamos esta semana.

Editar: acabo de usar el siguiente comando:

SELECT
    sqltext.TEXT,
    req.session_id,
    req.blocking_session_id,
    req.wait_type,
    req.wait_time,
    req.last_wait_type,
    req.wait_resource,
    req.open_transaction_count,
    req.transaction_id,
    req.total_elapsed_time
FROM
    sys.dm_exec_requests req
CROSS APPLY
    sys.dm_exec_sql_text(req.sql_handle) AS sqltext

y descubrí que mi consulta está esperando un bloqueo compartido (LCK_M_S) donde la sesión de bloqueo está esperando otro bloqueo compartido bloqueado por una sesión que no existe.

Edición 2: OK, la sesión existe (la encontré usando sys.dm_exec_sessions), pero no parece hacer nada ahora.

Edición 3: No puedo encontrar nada interesante sobre la sesión. Veo de qué servidor web proviene, pero no mucho más.

Edición 4: Edición 4: Encontramos un posible error en nuestro código: una función que no aseguraba que la conexión de la base de datos estuviera cerrada. Por otro lado, parecía que la transacción que la función estaba usando estaba dispuesta correctamente, en cuyo caso todos los bloqueos deberían haberse borrado. Todavía no está muy claro para mí, pero parece ser la razón probable. Vamos a arreglar el error y vigilarlo.

Para mí, este problema fue causado por una conexión de base de datos abierta por Visual Studio en pausa en modo de depuración. La detención del proceso de depuración permitió que la consulta se completara de inmediato.

¿Cuál es el tipo de espera para la consulta cuando se cuelga? Esto le dirá exactamente lo que está esperando. Busque e instale sp_whoisactive en el servidor y ejecute el procedimiento almacenado cuando tenga el problema. Esto le mostrará el spid y le dará el tipo de espera.

Lo más probable es que alguien que esté escribiendo en esa fila o en otra fila de esa página lo esté bloqueando o esté esperando que el disco responda.

Intente ejecutar DBCC CHECKDBel problema DB y espere hasta que termine. Si hay una inconsistencia de datos físicos que produce un comportamiento tan extraño, entonces es demasiado peligroso trabajar con este DB ya que puede perder todos sus datos.

1. Haga la copia de seguridad lo antes posible.
2. Verifique el DB.

PERO

Si la tabla tiene columnas BLOB con cantidades relativamente grandes de datos, es absolutamente normal que las comprobaciones de esta tabla tomen mucho tiempo.

No estoy realmente seguro de qué esperar como respuesta, pero si la tabla tiene más de 30 millones de filas, se espera que el comando DBCC se ejecute durante mucho tiempo.

Cuando tu dices:

Pero parece que ocurre solo para una pequeña fracción de registros

¿Quiere decir que le preocupa que no se escanee toda la mesa? Eso es normal si tiene un índice de ID, el índice se escaneará, lo que daría como resultado menos lecturas.