¿Por qué el estado "DbccFilesCompact" es "Suspendido"?

Estoy ejecutando el archivo SHRINK en un archivo de datos 600G.

Actualmente, el estado se informa como "suspendido" y sys.dm_exec_requests.percent_completepara los DbccFilesCompactinformes de comando que se está ejecutando (pero muy lentamente)

¿Hay alguna manera de verificar por qué se está suspendiendo y cómo hacer que funcione mejor?

FYI - Consulta SQL para verificar el estado

select T.text, R.Status, R.Command, DatabaseName = db_name(R.database_id)
       , R.cpu_time, R.total_elapsed_time, R.percent_complete
from   sys.dm_exec_requests R
       cross apply sys.dm_exec_sql_text(R.sql_handle) T
order by Command

No, no puedes comprobar por qué funciona lentamente, pero puedo darte algunas pistas:

1) En SQL 2005, la gestión de los índices no agrupados cambió del motor de almacenamiento (mi equipo) al procesador de consultas. Esto tiene muchos efectos secundarios, uno de los cuales es la velocidad con la que las páginas de datos de montón se pueden mover por contracción. Todos los registros de índice no agrupados contienen un vínculo de retroceso al registro de datos que están indexando; en el caso de un montón, este es un enlace físico a un número de registro en una página de datos específica. Cuando una página de datos de montón se mueve por contracción, todos los registros de índice no agrupados que se vinculan a los registros de esa página deben actualizarse con la nueva ubicación de la página. En 2000, esto fue hecho de manera muy eficiente por el propio motor de almacenamiento. A partir de 2005, esto debe hacerse llamando al procesador de consultas para actualizar los registros de índice no agrupados. Esto a veces es hasta 100 veces más lento que en 2000.

2) Los valores de LOB fuera de fila (ya sea tipos de datos de LOB reales o datos de desbordamiento de fila) no contienen un vínculo de retroceso a los datos o registro de índice del que forman parte. Cuando se mueve una página de registros LOB, se debe escanear toda la tabla o índice del que forman parte para determinar qué datos / registros de índice los apunta, para que puedan actualizarse con la nueva ubicación. Esto también es muy, muy lento.

3) Puede haber otro proceso usando la base de datos que está causando que el encogimiento se bloquee esperando los bloqueos que necesita para mover las páginas.

4) Es posible que tenga habilitado el aislamiento de instantáneas, y la reducción no puede mover páginas con enlaces de almacén de versiones hasta que se hayan completado las transacciones que requieren esas versiones anteriores.

5) Su subsistema de E / S puede tener poca potencia. Una longitud de cola de disco superior a los dígitos únicos bajos significa su subsistema de E / S en el cuello de botella.

Cualquiera o todos estos podrían estar contribuyendo a tiempos de ejecución lentos de reducción.

Sin embargo, en general, no desea ejecutar el encogimiento. Consulte esta publicación de blog para obtener más detalles: por qué no debe reducir sus archivos de datos .

¡Espero que esto ayude!

¡Puede ejecutar este script para verificar el porcentaje completado!

SELECT 
    percent_complete, 
    start_time, 
    status, 
    command, 
    estimated_completion_time, 
    cpu_time, 
    total_elapsed_time
    --,*
FROM 
    sys.dm_exec_requests
WHERE
    command = 'DbccFilesCompact'

Estoy reduciendo una base de datos en SQL Server 2008 SP1 y una forma de saber el progreso del comando Shrink es ejecutando sp_lock spid y, en su mayor parte, puedo ver que pone un bloqueo en el archivo 1 y luego, cuando lo hace, coloca un bloquear el ID de archivo 2, y así sucesivamente, de esta manera puedo decir cuándo está trabajando en el último ID de archivo y esta es mi indicación de que está casi completo.

Gracias,

Alex Aguilar

Descubrí cuál era el problema (en mi caso) y ofrezco aquí la solución que utilicé.

No tenía nada usando la base de datos, y master era la base de datos predeterminada en mi sesión, lo he verificado usando sp_who2. Luego hice clic derecho en la base de datos, seleccioné "tareas" y luego "reducir" y en "ok" el diálogo. Chequeando nuevamente con sp_who2, el estado es "suspendido" por varios minutos y luego de eso abortado porque "no se puede obtener un bloqueo exclusivo". Adivina, pero estoy seguro de que el diálogo en sí es el que causa eso.

Así que decidí ir a través de la línea de comando usando:

DBCC SHRINKDATABASE (myDataBase)

(La bruja está documentada en todas partes), luego el encogimiento tardó solo unos segundos.