Solución:
Solución 1:
No, no puedes comprobar por qué se está ejecutando lentamente, pero puedo darte algunas pistas:
1) En SQL 2005, la administración de í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 del montón se pueden mover mediante encogimiento. 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 vínculo físico a un número de registro en una página de datos específica. Cuando una página de datos de pila se mueve por encogimiento, todos los registros de índice no agrupados que tienen un vínculo de retroceso a los registros de esa página deben actualizarse con la nueva ubicación de la página. En 2000, esto lo hizo de manera muy eficiente 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. A veces, esto es hasta 100 veces más lento que en 2000.
2) Los valores de LOB fuera de la fila (ya sean tipos de datos de LOB reales o datos de desbordamiento de filas) no contienen un vínculo de retroceso a los datos o al 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 averiguar qué registro de datos / índice apunta a ellos, de modo que puedan actualizarse con la nueva ubicación. Esto también es muy, muy lento.
3) Puede haber otro proceso que use la base de datos y que esté causando que el encogimiento bloquee la espera de los bloqueos que necesita para mover las páginas.
4) Es posible que tenga habilitado el aislamiento de instantáneas, y Shrink no puede mover páginas con enlaces de tienda 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 la cola de disco superior a la de un solo dígito significa que su subsistema de E / S está en el cuello de botella.
Cualquiera o todos estos podrían estar contribuyendo a reducir los tiempos de ejecución de la contracción.
Sin embargo, en general, no desea ejecutar Shrink. Consulte esta publicación de blog para obtener más detalles: Por qué no debería reducir sus archivos de datos.
¡Espero que esto ayude!
Solucion 2:
¡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'
Solución 3:
Estoy reduciendo una base de datos en SQL Server 2008 SP1 y una forma en que puedo saber el progreso del comando Shrink es ejecutando sp_lock spid y, en su mayor parte, puedo ver que bloquea el archivo 1 y, cuando termina, coloca un bloquear en el ID de archivo 2, y así sucesivamente y de esta manera puedo saber cuándo está funcionando en el último ID de archivo y esta es mi indicación de que está casi completo.
Gracias,
Alex Aguilar