Przywracanie tempdb następuje automatycznie przy każdym starcie instancji — baza ta nie jest trwale zapisywana.
Jak SQL Server odtwarza bazę tempdb podczas uruchamiania
tempdb jest systemową bazą roboczą silnika Microsoft SQL Server. Służy do przechowywania danych tymczasowych, między innymi tabel tymczasowych, zmiennych tabelarycznych, wyników pośrednich sortowania, operacji agregowania, wersjonowania wierszy oraz innych struktur tworzonych na czas wykonywania zapytań. Jej zawartość nie jest przeznaczona do trwałego przechowywania danych aplikacji. Po zatrzymaniu instancji SQL Server dane znajdujące się w tempdb są usuwane.
Przy każdym uruchomieniu instancji SQL Server baza tempdb jest tworzona ponownie. W tym znaczeniu „przywracanie tempdb” nie oznacza odtwarzania jej z kopii zapasowej, lecz automatyczne utworzenie nowej, pustej bazy roboczej na podstawie zapisanej konfiguracji. Serwer odtwarza strukturę bazy, pliki danych i plik dziennika transakcji, a następnie udostępnia je zapytaniom wykonywanym przez użytkowników i aplikacje.
Rola bazy model podczas tworzenia tempdb
Jednym ze źródeł ustawień wykorzystywanych przy tworzeniu tempdb jest systemowa baza model. Jest ona szablonem dla nowych baz danych tworzonych w instancji SQL Server, a część jej właściwości jest używana także podczas inicjalizacji tempdb. Z tego powodu dostępność i poprawność bazy model ma znaczenie dla prawidłowego startu usługi SQL Server. Sama zawartość robocza wcześniejszej instancji tempdb nie jest jednak zachowywana.
Konfiguracja plików tempdb obejmuje między innymi ich nazwy logiczne, lokalizacje, rozmiary początkowe i ustawienia automatycznego powiększania. Te parametry są zapisywane w metadanych instancji, dlatego po restarcie SQL Server może ponownie utworzyć pliki w określonych katalogach. Jeżeli wskazany dysk nie istnieje, ścieżka jest niedostępna albo na dysku brakuje miejsca, proces tworzenia bazy może się nie powieść, mimo że wcześniejsze pliki tymczasowe nie muszą być odzyskiwane.
Co oznacza brak możliwości utworzenia tempdb
Problemy z automatycznym odtworzeniem tempdb pojawiają się najczęściej wtedy, gdy SQL Server nie może utworzyć lub otworzyć któregoś z wymaganych plików. Przyczyną może być brak wolnego miejsca, niedostępność woluminu, zmiana litery dysku, usunięcie katalogu, nieprawidłowa ścieżka zapisana w konfiguracji instancji albo ograniczenia uprawnień konta usługi. Znaczenie ma również rozmiar początkowy plików. Jeżeli skonfigurowany rozmiar przekracza ilość dostępnego miejsca, inicjalizacja może zakończyć się błędem na etapie uruchamiania.
Diagnostyka powinna zaczynać się od sprawdzenia dziennika błędów SQL Server oraz komunikatów systemu Windows, a następnie obejmować lokalizację plików i stan właściwych woluminów. Po uruchomieniu instancji można odczytać informacje o plikach za pomocą widoku katalogowego sys.database_files w bazie tempdb, a także sprawdzić rozmiary i ustawienia wzrostu. Przykładowe zapytanie SELECT name, physical_name, size, growth FROM tempdb.sys.database_files; pokazuje podstawowe parametry plików dostępnych w aktualnie działającej instancji. Takie sprawdzenie nie odzyskuje danych historycznych, lecz pozwala potwierdzić, czy baza została utworzona poprawnie i gdzie znajdują się jej pliki.
Różnica między odtworzeniem tempdb a odzyskaniem danych
tempdb nie jest bazą przeznaczoną do archiwizacji wyników pracy aplikacji. SQL Server nie obsługuje wykonywania kopii zapasowej tej systemowej bazy w taki sposób, jak w przypadku baz użytkownika. Nie można więc odtworzyć poprzedniej zawartości tempdb po restarcie ani traktować jej plików jako źródła trwałego odzyskiwania dokumentów, rekordów biznesowych lub historii transakcji. Jeżeli dane powinny przetrwać ponowne uruchomienie usługi, muszą zostać zapisane w odpowiedniej bazie użytkownika albo w innym trwałym magazynie.
W praktyce przywracanie tempdb oznacza kontrolę procesu startowego, prawidłowych ścieżek, dostępnego miejsca i zgodności ustawień z obciążeniem instancji. Zmiana lokalizacji plików, korekta rozmiaru początkowego lub usunięcie niepotrzebnych dodatkowych plików wymaga ostrożności i zwykle zaplanowanego restartu usługi SQL Server. Celem nie jest zachowanie tymczasowych danych, lecz zapewnienie, aby po uruchomieniu silnik otrzymał pustą, dostępną bazę roboczą o parametrach pozwalających wykonywać zapytania oraz operacje wewnętrzne.
