Comportamiento extraño DBCC Shrinkfile

Estoy intentando ejecutar un dbcc shrinkfile en trozos de 1 GB contra una base de datos donde el 95% de los datos se han archivado y eliminado. Estoy a la izquierda con un archivo de 235 GB donde 9 GB son datos / índices. Quiero reducir esto a 50 GB. Sé que reducir los archivos de la base de datos es malo, causa fragmentación, etc. Como parte de la purga / reducción de datos, también tenemos un script idnex de reconstrucción.

Cuando ejecuto mi script dbcc shrinkfile contra la base de datos en mi propia estación de trabajo (quad core, 12 GB de RAM, 2 x unidades SATA), el encogimiento toma alrededor de 8-10 minutos.

Cuando se ejecuta el código idéntico contra una copia idéntica de la purga de datos posteriores a la base de datos, en nuestro entorno de prueba (más de 80 núcleos, 128 GB de RAM, SSD SAN), lleva 70 minutos. Para tener en cuenta, hay poca actividad en este servidor en el momento de ejecución del archivo de reducción. Se ha ejecutado 4 veces con resultados idénticos.

Luego tomé un enfoque diferente, de mover los 9 GB restantes a un grupo de archivos diferente y un archivo físico. Ejecutar dbcc shrinkfile en el archivo vacío de 230 GB para reducirlo a 50 GB, en mi propia estación de trabajo tarda <1 minuto.

Con este mismo enfoque, en el entorno de prueba, nuevamente lleva más de 70 minutos.

He tomado una instantánea de los estadios de espera antes y después según el guión de Brent Ozar durante los 70 minutos de ejecución en el entorno de prueba, y los tipos de espera regresaron sin mostrar nada de qué preocuparse. Las 3 filas superiores a continuación:

Segundo tiempo de muestra Duración de la muestra en segundos wait_type Tiempo de espera (segundos) Número de esperas Promedio ms por espera
2013-05-28 11: 24: 22.893 3600 ESCRITORIO 160.8 143066 1.1
2013-05-28 11: 24: 22.893 3600 CXPACKET 20.9 13915 1.5
2013-05-28 11: 24: 22.893 3600 PAGELATCH_EX 11.1 443038 0.0

El registro de eventos de Windows no muestra nada inusual. Me dirijo a rascar en este punto, por qué está tardando tanto en el hardware ninja, en comparación con mi estación de trabajo independiente.

— ptreston
fuente

Revise la base de datos y luego pruébelo.

— Kin Shah

borre las estadísticas de cierre antes del encogimiento y captúrelas después del shrnik, en ambas máquinas. sys.dm_os_latch_stats

— Remus Rusanu

Además, @@versionen ambos

— Remus Rusanu

¿Los datos que se eliminaron eran datos de blob o datos normales? La copia en su estación de trabajo se eliminó allí o hizo una copia de seguridad del sistema de control de calidad después de la eliminación y luego la restauró en su máquina.

— mrdenny

Shrinkfile en un archivo de datos es una operación de subproceso único que reutiliza un pequeño búfer de memoria.

Entonces, el hardware Ninja no tiene una ventaja con la memoria adicional y los 80 núcleos.

Sin embargo, su PC local tiene el beneficio de la latencia de E / S local (disco local, es decir, no tener que realizar múltiples viajes a la SAN).

— John Alan
fuente