Comportement étrange DBCC Shrinkfile

J'essaie d'exécuter un fichier de rétrécissement dbcc en morceaux de 1 Go sur une base de données où 95% des données ont été archivées et supprimées. Je suis parti avec un fichier de 235 Go où 9 Go sont des données / index. Je veux réduire cela à 50 Go. Je sais que la réduction des fichiers de base de données est mauvaise, elle provoque une fragmentation, etc. Dans le cadre de la purge / réduction des données, nous avons également un script de reconstruction d'idnex.

Lorsque j'exécute mon script de fichier rétractable dbcc sur la base de données sur mon propre poste de travail (quad core, 12 Go de RAM, 2 disques SATA), le rétrécissement prend environ 8 à 10 minutes.

Lors de l'exécution du code identique sur une copie identique de la purge des données de la base de données, dans notre environnement de test (80+ cœurs, 128 Go de RAM, SSD SAN), cela prend 70 minutes. A noter, il y a peu d'activité sur ce serveur au moment de l'exécution du fichier de réduction. Il a été exécuté 4 fois avec des résultats identiques.

J'ai ensuite adopté une approche différente, en déplaçant les 9 Go restants vers un groupe de fichiers et un fichier physique différents. L'exécution de dbcc shrinkfile sur le fichier vide de 230 Go pour le réduire à 50 Go, sur mon propre poste de travail, prend <1 minute.

Avec cette même approche, sur l'environnement de test, cela prend à nouveau plus de 70 minutes.

J'ai pris un instantané des statistiques d'attente avant et après selon le script de Brent Ozar au cours de la course de 70 minutes sur l'environnement de test, et les types d'attente sont revenus ne montrant rien à craindre. 3 premières lignes ci-dessous:

Deuxième temps d'échantillonnage Durée d'échantillon en secondes wait_type Temps d'attente (secondes) Nombre d'attentes ms ms par attente
2013-05-28 11: 24: 22.893 3600 WRITELOG 160.8 143066 1.1
28/05/2013 11: 24: 22.893 3600 CXPACKET 20.9 13915 1.5
28/05/2013 11: 24: 22.893 3600 PAGELATCH_EX 11.1 443038 0.0

Le journal des événements Windows ne montre rien d'inhabituel. Je vais me gratter à ce stade, pourquoi cela prend si longtemps sur le matériel ninja, par rapport à mon poste de travail autonome.

Shrinkfile sur un fichier de données est une opération monothread, réutilisant une petite mémoire tampon.

Le matériel Ninja n'a donc pas d'avantage avec la mémoire supplémentaire et les 80 cœurs.

Votre PC local a cependant l'avantage d'une latence d'E / S locale (disque local, c'est-à-dire ne pas avoir à effectuer plusieurs trajets vers le SAN).