Próbuję uruchomić plik skurczowy dbcc w porcjach 1 GB w bazie danych, w której 95% danych zostało zarchiwizowanych i usuniętych. Mam plik 235 GB, w którym 9 GB to dane / indeksy. Chcę to zmniejszyć do 50 GB. Wiem, że zmniejszanie plików bazy danych jest złe, powoduje fragmentację itp. W ramach czyszczenia / zmniejszania danych mamy również skrypt odbudowywania idnex.
Kiedy uruchamiam skrypt dbinkfile dbcc w bazie danych na własnej stacji roboczej (czterordzeniowy, 12 GB pamięci RAM, 2 dyski SATA), zmniejszenie zajmuje około 8-10 minut.
Podczas uruchamiania identycznego kodu na identycznej kopii czyszczenia danych po wysłaniu do bazy danych, w naszym środowisku testowym (ponad 80 rdzeni, 128 GB pamięci RAM, SSD SAN), zajmuje to 70 minut. Należy zauważyć, że na tym serwerze aktywność w momencie zmniejszania pliku jest niewielka. Uruchomiono go 4 razy z identycznymi wynikami.
Następnie podjąłem inne podejście, przenosząc pozostałe 9 GB do innej grupy plików i pliku fizycznego. Uruchomienie pliku skurczowego dbcc na pustym pliku 230 GB, aby go zmniejszyć do 50 GB, na mojej stacji roboczej zajmuje mniej niż 1 minutę.
Przy takim samym podejściu w środowisku testowym znów zajmuje to ponad 70 minut.
Zrobiłem migawkę statusów oczekiwania przed i po, zgodnie ze skryptem Brenta Ozara podczas 70-minutowej pracy w środowisku testowym, a typy oczekiwania powróciły, nie wykazując żadnych obaw. 3 górne wiersze poniżej:
Czas drugiej próbki Czas trwania próbki w sekundach typ_wejścia Czas oczekiwania (w sekundach) Liczba oczekiwań Śr. Ms na oczekiwanie 2013-05-28 11: 24: 22.893 3600 WRITELOG 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
Dziennik zdarzeń systemu Windows nie pokazuje nic niezwykłego. W tym momencie zaczynam drapać się, dlaczego tak długo trwa sprzęt ninja, w porównaniu do mojej autonomicznej stacji roboczej.
sys.dm_os_latch_stats
@@versionw obu przypadkach