Dlaczego status „DbccFilesCompact” ma status „Zawieszony”?

Korzystam z pliku SHRINK na pliku danych 600G.

Obecnie status jest zgłaszany jako „zawieszony”, a sys.dm_exec_requests.percent_completedla DbccFilesCompactraportów poleceń, że jest uruchomiony (ale bardzo wolno)

Czy istnieje sposób, aby sprawdzić, dlaczego jest zawieszony i jak sprawić, by działał płynniej?

FYI - Zapytanie SQL do sprawdzania statusu

select T.text, R.Status, R.Command, DatabaseName = db_name(R.database_id)
       , R.cpu_time, R.total_elapsed_time, R.percent_complete
from   sys.dm_exec_requests R
       cross apply sys.dm_exec_sql_text(R.sql_handle) T
order by Command

Nie, nie możesz sprawdzić, dlaczego działa wolno, ale mogę dać ci kilka wskazówek:

1) W SQL 2005 zarządzanie indeksami nieklastrowanymi zostało zmienione z silnika pamięci masowej (mojego zespołu) na procesor zapytań. Ma to wiele skutków ubocznych, z których jednym jest szybkość, z jaką strony danych sterty mogą być przenoszone przez zmniejszanie. Wszystkie nieklastrowane rekordy indeksu zawierają odsyłacz do rekordu danych, który indeksują - w przypadku sterty jest to fizyczny link do numeru rekordu na określonej stronie danych. Gdy strona danych sterty zostanie przesunięta przez zmniejszenie, wszystkie nieklastrowane rekordy indeksu, które odsyłają do rekordów na tej stronie, muszą zostać zaktualizowane o nowe położenie strony. W 2000 r. Zostało to wykonane bardzo skutecznie przez sam silnik pamięci masowej. Począwszy od 2005 r., Należy to zrobić, wywołując procesor zapytań, aby zaktualizować nieklastrowane rekordy indeksu. Czasami jest to nawet 100 razy wolniej niż w 2000 roku.

2) Wartości LOB poza wierszem (rzeczywiste typy danych LOB lub dane przepełnienia wiersza) nie zawierają linku zwrotnego do danych lub rekordu indeksu, których są częścią. Po przeniesieniu strony rekordów LOB cała tabela lub indeks, którego są częścią, musi zostać przeskanowana, aby dowiedzieć się, który rekord danych / indeksu wskazuje na nich, aby można je było zaktualizować o nową lokalizację. Jest to również bardzo, bardzo wolne.

3) Może istnieć inny proces korzystający z bazy danych, który powoduje, że kurczenie się blokuje w oczekiwaniu na blokady potrzebne do przenoszenia stron.

4) Możliwe, że masz włączoną izolację migawek i funkcja zmniejszania nie może przenosić stron z linkami do sklepu z wersjami, dopóki transakcje wymagające starszych wersji nie zostaną zakończone.

5) Twój podsystem we / wy może być niedociążony. Długość kolejki dyskowej większa niż niskie pojedyncze cyfry oznacza podsystem we / wy w wąskim gardle.

Dowolne lub wszystkie z nich mogą przyczyniać się do spowolnienia czasu kurczenia się.

Zasadniczo jednak nie chcesz uruchamiać programu zmniejszającego się. Zobacz ten post na blogu, aby uzyskać szczegółowe informacje: Dlaczego nie powinieneś zmniejszać plików danych .

Mam nadzieję że to pomoże!

Możesz uruchomić ten skrypt, aby sprawdzić procent ukończenia!

SELECT 
    percent_complete, 
    start_time, 
    status, 
    command, 
    estimated_completion_time, 
    cpu_time, 
    total_elapsed_time
    --,*
FROM 
    sys.dm_exec_requests
WHERE
    command = 'DbccFilesCompact'

Zmniejszam bazę danych w SQL Server 2008 SP1 i jednym ze sposobów, w jaki mogę stwierdzić, że postęp polecenia Shrink jest wykonanie sp_lock spid, i w większości przypadków widzę, że blokuje on plik 1, a kiedy to zrobi, umieszcza zablokuj plik id 2 itd. i w ten sposób mogę stwierdzić, kiedy działa na ostatnim identyfikatorze pliku, a to jest moje wskazanie, że jest prawie ukończone.

Dzięki,

Alex Aguilar

Odkryłem, na czym polega problem (w moim przypadku) i oferuję tutaj rozwiązanie, z którego korzystałem.

Nie miałem nic za pomocą bazy danych, a master był domyślną bazą danych w mojej sesji, zweryfikowałem to za pomocą sp_who2. Następnie kliknąłem prawym przyciskiem myszy bazę danych, wybrałem „zadania”, a następnie „zmniejsz” i „ok” w oknie dialogowym. Sprawdzając ponownie za pomocą sp_who2, status jest „zawieszony” na kilka minut, a po tym przerywany, ponieważ „nie można uzyskać wyłącznej blokady”. Zgadnij sam, ale jestem pewien, że to właśnie ten dialog powoduje.

Postanowiłem więc przejść przez linię poleceń, używając:

DBCC SHRINKDATABASE (myDataBase)

(Czarownica jest wszędzie udokumentowana), a następnie kurczenie się zajęło zaledwie kilka sekund.