Usuwanie wtórnych plików danych. DBCC SHRINKFILE: Nie można przenieść strony, ponieważ jest to strona tabeli roboczej

Mam za dużo dodatkowych plików danych (.ndf) tempdb. Aby usunąć nadmiar plików, muszę opróżnić plik (zawartość zostanie przeniesiona do innych plików):

DBCC SHRINKFILE('tempdbfile8', EMPTYFILE);

a następnie usuń plik:

ALTER DATABASE tempdb REMOVE FILE tempdbfile8;

Ale EMPTYFILEpolecenie zwraca błąd:

DBCC SHRINKFILE: Page 8:41920 could not be moved because it is a work table page.
Msg 2555, Level 16, State 1, Line 2
Cannot move all contents of file "tempdbfile8" to other places to complete the emptyfile operation.

Nie martw się, muszę tylko zlokalizować obiekt, który używa tej strony, aby coś z tym zrobić:

DBCC TRACEON (3604)
DBCC PAGE(2,8,41920) --dbid=2, fileid=8, pageid=41920

Polecenie zwraca wiele informacji, wśród nich identyfikator_obiektu. Ale:

Metadata: ObjectId = 0

Nie mam pojęcia, co z tym zrobić. Który kot powstrzyma tę stronę przed przeniesieniem? Jak zlokalizować ten obiekt, proces, sesję lub cokolwiek to jest? Jakakolwiek pomoc będzie mile widziana, ale należy pamiętać, że pozostawienie wszystkiego bez zmian lub usunięcie innego pliku nie jest prawidłowym rozwiązaniem tego problemu;).

EDYTOWAĆ:

Usuwam pliki, ponieważ postępowaliśmy zgodnie z „najlepszą praktyką” tworzenia jednego pliku na rdzeń procesora (ten sam rozmiar początkowy, to samo tempo wzrostu). Ale o ile wiem, dopóki nie napotkasz problemów rywalizacji, nie ma sensu tworzyć dodatkowych plików tempdb na tym samym urządzeniu. W naszym przypadku ma to sens, ponieważ mamy włączone MPIO , a urządzenie pamięci masowej może obsługiwać 4 ścieżki. Ale był błąd i ostatecznie otrzymaliśmy 5 plików z 6-rdzeniowym procesorem. To więcej niż ścieżki MPIO, mniej niż rdzenie procesora i nie jest to liczba parzysta. Nie może powodować żadnych problemów, ale po prostu wydaje się niewłaściwy :).

W końcu mogłem opróżnić i usunąć plik bez ponownego uruchamiania serwera, ustawiając jedną z baz danych (które podejrzewałem, że spowodowały problem) na tryb pojedynczego użytkownika (natychmiastowe wycofanie). Udało się, ale miałem szczęście. To, czego naprawdę chcę, to zawsze móc śledzić stronę :).

— Adam Luniewski
źródło

Komenda DBCC PAGE jest niepoprawna, powinna wyglądać jak strona dbcc (2 41920,1). 1,2,3 zależy od tego, co chcesz w danych wyjściowych.

— Shanky

Jeśli powyższe nie działa, być może trzeba to zrobić sprzętowo, usuwając pliki, a następnie ponownie uruchamiając serwer SQL, aby używał tylko plików, które nie zostały usunięte. Czy możesz odnieść się do tego linku daveturpin.com/2011/07/how-to-drop-a-tempdb-database-file

— Shanky

@Shanky Polecenie jest prawidłowe. 0..3 można przekazać jako czwarty parametr: dbcc page ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])O twoim rozwiązaniu: zadziałałoby, ale naprawdę chciałbym to zrobić bez wyłączania instancji.

— Adam Luniewski

Ok .. Mówiłem ci o prostszej formie strony dbcc. Uwaga: polecenie nieudokumentowane. Czy sprawdziłeś link, który opublikowałem

— Shanky

Myślę, że nie jest możliwe rozwiązanie tego problemu bez ponownego uruchomienia instancji. Oczywiście próbujesz wyśledzić, czym jest ten stół roboczy (co pomogłoby ustalić, kto jest jego właścicielem), i to się nie udało. Wybierz hit lub żyj z dodatkowymi plikami, aż będziesz mógł ponownie uruchomić.

— Aaron Bertrand

Odpowiedzi:

Ponowne uruchomienie serwera powinno wystarczyć - te stoły robocze powinny zostać wyczyszczone. Ale prawdopodobnie uruchomiłbym go w trybie pojedynczego użytkownika (-m), aby uniemożliwić innym procesom tworzenie tabel roboczych przed pomyślnym usunięciem tych plików. Następnie ponownie zdefiniuj wymagane pliki tempdb; być może usuwając niepotrzebne pliki, zmieniając rozmiary itp. Powinieneś także upewnić się, że masz parzystą liczbę plików, że wszystkie są ustawione na ten sam rozmiar i że wszystkie mają takie same ustawienia automatycznego wzrostu (w MB, a nie%). I może to być dobry moment na rozważenie TF 1117 i TF 1118 ( punkt początkowy ).

Byłbym bardzo ostrożny wobec sugestii, aby po prostu usunąć pliki z systemu plików przed ponownym uruchomieniem programu SQL Server - może się w ogóle nie uruchomić.

(Byłbym również ciekawy, na czym polega faktyczny problem. Zbyt duża liczba plików naprawdę cię nie skrzywdzi.)

— Aaron Bertrand
źródło

@@ Aaron oczywiście musisz być ostrożny przy usuwaniu go musi być pusty, ale jest to udokumentowane tutaj msdn.microsoft.com/en-gb/library/ms175574.aspx . Próbowałem i SQl Server tempdb jest w trybie online.

— Shanky

@Shanky Próbowałem raz przejechać 138 mil na godzinę i nie zostałem zatrzymany. Czy to oznacza, że powinienem to robić dalej i że nie ma szans, że jutro mnie pociągną? Znacznie bezpieczniej jest najpierw wypróbować właściwy sposób, zanim zasugerujesz bardziej ryzykowny sposób. MOIM ZDANIEM. Zwłaszcza, że nie może teraz opróżnić pliku - czy sądzisz, że możliwe jest, że jest w nim coś innego niż stół roboczy, na który narzeka komunikat o błędzie? Błąd nie tworzy wyczerpującej listy wszystkich obiektów, wyświetla tylko pierwszy obiekt.

— Aaron Bertrand

Jest coś, co faktycznie używa tempdb, więc nie pozwala opróżnić pliku, którego trudno zgadnąć. Oby użył operatora sortowania w zapytaniu, które wciąż wymaga tempdb. DMV może pomóc w znalezieniu sys.dm_db_task_space_usage sys.dm_db_session_space_usage sys.dm_db_file_space_usage

— Shanky

Ponowne uruchomienie jest tutaj opcją, ale nawet jeśli nie opróżni pliku i spróbuje upuścić plik tempdb, powiedzieliby, że pliku tempdb nie można usunąć, ale jednocześnie katalog systemowy jest aktualizowany i po ponownym uruchomieniu plik zniknie. Domyślam się, że jest to domyślne zachowanie z tempdb, więc zasugerowałem i nadal myślę, że usunięcie pliku danych będzie działać, nawet jeśli zostanie wykorzystane. To samo znajduje się w linku, który zamieściłem w moim drugim komentarzu.

— Shanky

@Shanky, te DMV mogą zwrócić tysiące wierszy dla wszystkich rzeczy, które nie mają nic wspólnego z danym plikiem - więc jak zamierzasz to zawęzić? Również dlatego, że przy użyciu tej metody musisz zrestartować, dlaczego nie spróbować najpierw prostszej metody? Po prostu nie zgadzam się z tobą, że „trudna droga” powinna być pierwszą sugestią, przepraszam.

— Aaron Bertrand

https://social.msdn.microsoft.com/Forums/en-US/2a00c314-f35e-4900-babb-f42dcde1944b/dbcc-shrinkfile-page-411283400-could-not-be-moved-because-it-is- a-work-table-page? forum = sqldatabaseengine

Jak zaproponował Mike na forum msdn, tabele robocze są najczęściej związane z pamięcią podręczną planu. Wyczyszczenie ich spowoduje również usunięcie stołu roboczego, a następnie możesz zmniejszyć Tempdb. To zadziałało dla mnie. Oszczędza to również ponownego uruchomienia serwera. Będzie trochę narzutu, ponieważ SQL Server będzie musiał ponownie odtworzyć plany wykonania.

— Sajeesh
źródło