Sto tentando di eseguire un file di ridimensionamento dbcc in blocchi di 1 GB su un database in cui il 95% dei dati è stato archiviato ed eliminato. Ho lasciato un file da 235 GB in cui 9 GB sono dati / indici. Voglio ridurlo a 50 GB. So che la riduzione dei file di database è dannosa, causa la frammentazione, ecc. Come parte dell'eliminazione / riduzione dei dati abbiamo anche uno script idnex ricostruito.
Quando eseguo il mio script shrinkfile dbcc sul database sulla mia workstation (quad core, 12 GB di RAM, 2 unità SATA), la riduzione richiede circa 8-10 minuti.
Quando si esegue lo stesso codice su una copia identica dell'eliminazione dei dati post del database, nel nostro test testing, (80+ core, 128 GB di RAM, SSD SAN), sono necessari 70 minuti. Da notare, c'è poca attività su questo server al momento dell'esecuzione del file di riduzione. È stato eseguito 4 volte con risultati identici.
Ho quindi adottato un approccio diverso, quello di spostare i rimanenti 9 GB in un diverso filegroup e file fisico. L'esecuzione di dbcc shrinkfile sul file vuoto da 230 GB per ridurlo a 50 GB, sulla mia workstation richiede <1 minuto.
Con questo stesso approccio, nell'ambiente di test, sono necessari altri 70 minuti.
Ho scattato un'istantanea di waitstats prima e dopo secondo la sceneggiatura di Brent Ozar durante i 70 minuti di esecuzione nell'ambiente di test, e i waittypes sono tornati mostrando nulla di cui preoccuparsi. Prime 3 righe di seguito:
Secondo tempo di campionamento Durata del campione in secondi wait_type Tempo di attesa (secondi) Numero di attese Media ms per attesa 28/05/2013 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
Il registro eventi di Windows non mostra nulla di insolito. Sto andando a grattare a questo punto, perché ci vuole così tanto tempo sull'hardware ninja, rispetto alla mia workstation autonoma.
sys.dm_os_latch_stats
@@versionsu entrambi