Tempdb Integrity Check: DBCC could not obtain a lock on object “id” because the lock request timeout period was exceeded.
Cuando se ejecuta los comandos DBCC CHECKDB, DBCC CHECKALLOC, DBCC CHECKCATALOG, DBCC CHECKTABLE y DBCC CHECKFILEGROUP se creará previamente una instantánea de la base de datos y sobre esta se realizará la comprobación lógica y física de los objetos. SQL Server asegura que esta instantánea sea coherente y luego de usarla la elimina. Con esta estrategia de evitará problemas de bloqueos y operaciones concurrentes cuando esté ejecutándose uno de los comandos anteriores. En el caso que SQL Server no pueda generar una instantánea procederá a ejecutarlo contra la base de datos real, y usará implicitamente la opción WITH TABLOCK para bloquear las tablas y de este manera asegurar que la comprobación sea confiable.
Existen casos donde estos bloqueos no logran concretarse. Hoy nuevamente se volvió a presentar el caso en uno de mis servers (error 5245), y en este post voy a comentarlo puntualmente para la tempdb, pero antes quiero aclarar lo siguiente:
- Los comandos DBCC CHECKCATALOG, DBCC CHECKALLOC no son aplicables contra la tempdb.
- En la práctica, ejecutar DBCC CHECKDB contra la tempdb sólo comprobará de la asignación y la integridad estructural de todas las tablas y vistas indizadas (es lo mismo que ejecutar DBCC CHECKTABLE), más no la comprobación de catálogos y estructuras de asignación de espacio en disco de la base de datos.
Durante la ejecución de DBCC CHECKDB (o también de DBCC CHECKTABLE y DBCC CHECKFILEGROUP) contra la tempdb no se creará una instantánea debido a restricciones internas, esto significa que SQL Server debería bloquear las tablas reales de la tempdb, sin embargo, no es garantizado que los bloqueos se lleven acabo y se disparará el siguiente error:
Msg 5245, Level 16, State 1, Line 1
DBCC could not obtain a lock on object 4 because the lock request timeout period was exceeded.
Cuando ejecute DBCC CHECKDB usted podrá verificar que se trata de intentos de obtención de bloqueos de las tablas del sistema, para esto podemos usar la vista sys.dm_exec_requests donde la columnas command devuelve DBCC SYS CHECK, wait_resource nos indica que se trata explícitamente cuando se inicia la comprobación de la tabla del sistema con id igual a 4, y percent_complete nos dice que el avance de la comprobación actual es cero. Ahora consultando sys.objects, el objeto con id igual a 4 refiere a la tabla sysrowsetcolumns (tabla del sistema).
SELECT session_id, status, command, database_id, blocking_session_id,wait_type, wait_resource, percent_complete
FROM sys.dm_exec_requests
WHERE session_id=<id_session_checkdb_en_ejecución>
Para averiguar más detalles del wait_type (modo de bloqueo) y wait_resource (objeto que se intenta bloquear en este caso) podemos usar sys.dm_os_waiting_tasks, con lo cual se comprabará lo dicho anteriormente respecto al recurso.
SELECT session_id, wait_type,blocking_session_id, resource_description
FROM sys.dm_os_waiting_tasks
WHERE session_id=<id_session_checkdb_en_ejecución>
Bajo este escenario la recomendación sería reiniciar el servicio, o esperar a que el recurso se libere. No siempre es muy recomendable el uso de DBCC CHECKDB y DBCC CHECKTABLE contra la tempdb, aveces esto podría ocasionar pérdidas de datos, opte por reiniciar el servicio en caso de ser factible, pues todo reinicio implica que la tempdb se vuelva a crear, así como también la ejecución interna de DBCC CHECKDB antes de ponerla en estado online. Esta comprobación interna con DBCC CHECKDB se aplica también para todas las bases de datos usuarios existentes y demás bases de datos del sistema (master, msdb, model, distribution). Espero sirva.
PercyReyes,