Awaria tempdb

Awaria tempdb to problem dotyczący tymczasowej bazy systemowej wykorzystywanej przez SQL Server do operacji pośrednich.

Rola tempdb w działaniu SQL Server

tempdb jest tymczasową bazą systemową używaną przez Microsoft SQL Server podczas wykonywania wielu operacji wewnętrznych i użytkowych. Silnik zapisuje w niej między innymi tabele tymczasowe, zmienne tabelaryczne, wyniki pośrednie sortowania, dane robocze operatorów agregacji oraz struktury wykorzystywane przy tworzeniu indeksów. Z tempdb mogą również korzystać mechanizmy izolacji migawkowej, wersjonowania wierszy i niektóre funkcje obsługi zapytań równoległych. Jej zawartość nie jest zachowywana po ponownym uruchomieniu usługi SQL Server, ponieważ baza jest tworzona od nowa podczas startu instancji.

Awaria tempdb nie musi oznaczać uszkodzenia plików w takim samym znaczeniu jak awaria trwałej bazy danych. Często jest skutkiem braku wolnego miejsca, błędnej konfiguracji plików, problemu z podsystemem dyskowym, nadmiernych operacji zapisujących dane tymczasowe albo konfliktu podczas korzystania ze struktur alokacyjnych. Objawem może być zatrzymanie pojedynczego zapytania, błędy wielu sesji jednocześnie, długie oczekiwanie na zasoby, nieudany start instancji lub niemożność wykonania operacji wymagających obszaru roboczego.

Objawy i mechanizmy typowej awarii

Jednym z najczęstszych symptomów jest komunikat o braku miejsca w tempdb lub na woluminie zawierającym jej pliki. W takiej sytuacji SQL Server może nie utworzyć tabeli tymczasowej, nie zakończyć sortowania, nie zapisać danych wersji wierszy albo przerwać zapytanie z powodu niemożności rozszerzenia pliku. Samo zwiększenie maksymalnego rozmiaru pliku nie rozwiązuje problemu, jeżeli system plików nie ma już wolnej przestrzeni albo wzrost pliku jest ograniczony przez konfigurację.

Przyczyną może być także niekontrolowany przyrost obiektów tymczasowych tworzonych przez aplikację, długotrwała transakcja blokująca zwalnianie wersji wierszy lub zapytanie wymagające dużego obszaru roboczego. Do obciążenia przyczyniają się między innymi sortowania, operatory HASH JOIN, agregacje, przebudowy indeksów oraz zapytania zwracające duże ilości danych pośrednich. Jeżeli pamięć przydzielona na wykonanie zapytania jest niewystarczająca, SQL Server może przenieść część pracy do tempdb, powodując intensywny zapis i odczyt.

Inny rodzaj problemu występuje przy nieprawidłowym rozmieszczeniu plików danych i pliku dziennika transakcji. Zbyt mała liczba plików danych, nierówne rozmiary początkowe lub automatyczny przyrost ustawiony w niepraktyczny sposób mogą zwiększać rywalizację o strony alokacji. W starszych konfiguracjach widoczne są wtedy oczekiwania związane z PAGELATCH, dotyczące stron systemowych w pamięci, a niekoniecznie opóźnień samego urządzenia dyskowego.

Rozpoznanie źródła problemu w instancji

Diagnostykę należy rozpocząć od ustalenia, czy problem dotyczy miejsca, wydajności, alokacji, blokowania czy integralności plików. Widoki katalogowe SQL Server pozwalają sprawdzić rozmiary plików tempdb, ich ścieżki, ustawienia automatycznego przyrostu oraz bieżące wykorzystanie przestrzeni. Przydatne są między innymi sys.database_files, sys.dm_db_file_space_usage i sys.dm_db_session_space_usage. Dane te należy zestawić z wolnym miejscem raportowanym przez system operacyjny oraz z czasem wystąpienia błędu.

Warto przeanalizować dziennik błędów SQL Server i historię zdarzeń systemowych. Komunikaty o niemożności powiększenia pliku, błędach wejścia-wyjścia, przekroczeniu limitu rozmiaru lub nieudanym otwarciu ścieżki wskazują na różne klasy przyczyn. Błędy wejścia-wyjścia wymagają sprawdzenia urządzenia i systemu plików, natomiast komunikaty o oczekiwaniach lub wysokim zużyciu przestrzeni wymagają korelacji z aktywnymi sesjami i konkretnymi zapytaniami. Nie należy usuwać plików tempdb ręcznie ani modyfikować ich położenia poza mechanizmami SQL Server.

Przy analizie obciążenia trzeba sprawdzić sesje zużywające przestrzeń tymczasową, długo trwające transakcje oraz zapytania oczekujące na zapis lub odczyt. Monitorowanie powinno obejmować także czas opóźnień dyskowych, przepustowość woluminu i częstotliwość automatycznego przyrostu. Jeżeli awaria powtarza się po restarcie, sam restart może tylko chwilowo usunąć zawartość tempdb, ale nie usunie przyczyny związanej z zapytaniem, konfiguracją, miejscem na dysku albo wydajnością podsystemu pamięci masowej.

Bezpieczne przywrócenie pracy i zapobieganie powtórce

Usuwanie skutków awarii powinno rozpocząć się od zabezpieczenia informacji diagnostycznych: komunikatów błędów, czasu zdarzenia, stanu plików i listy aktywnych sesji. Następnie można usunąć źródło nadmiernego zużycia przestrzeni, zwolnić miejsce na właściwym woluminie, skorygować rozmiary plików lub zaplanować kontrolowany restart usługi, jeżeli baza nie może zostać ponownie otwarta. Zmiany konfiguracji muszą uwzględniać wszystkie pliki danych oraz plik dziennika, a także przewidywane obciążenie instancji.

Profilaktyka obejmuje dobranie początkowych rozmiarów plików, ustawienie przewidywalnych przyrostów oraz zapewnienie wystarczającego zapasu przestrzeni. W instalacjach o dużym obciążeniu analizuje się rozmieszczenie plików na odpowiednio wydajnych woluminach, równomierność ich rozmiarów i występowanie oczekiwań alokacyjnych. Równolegle należy optymalizować zapytania generujące duże wyniki pośrednie, kontrolować długość transakcji i obserwować mechanizmy wersjonowania wierszy.

Diagnostyka powinna rozróżniać awarię samej bazy tymczasowej od problemu aplikacji, systemu operacyjnego, dysku lub całej instancji SQL Server. Pochopne usuwanie plików, ręczne kopiowanie ich między lokalizacjami albo zwiększanie rozmiaru bez sprawdzenia przyczyny może doprowadzić do kolejnych błędów. W środowisku, w którym tempdb jest krytycznym elementem pracy serwera, potrzebna jest analiza logów, konfiguracji, zapytań i stanu pamięci masowej, a nie tylko jednorazowe ponowne uruchomienie usługi.