Backup bazy tempdb jest niedozwolony, ponieważ ta tymczasowa baza jest tworzona od nowa przy każdym uruchomieniu serwera.
Dlaczego SQL Server nie wykonuje kopii zapasowej tempdb
tempdb jest systemową bazą danych silnika Microsoft SQL Server przeznaczoną do przechowywania danych tymczasowych. Korzystają z niej między innymi tabele tymczasowe, zmienne tabelaryczne, wyniki pośrednie sortowania, operacje grupowania, agregacje, kursory oraz wersjonowanie wierszy używane przez określone poziomy izolacji transakcji. Zawartość tej bazy nie jest traktowana jako trwały zbiór danych aplikacyjnych. Z tego powodu SQL Server nie obsługuje wykonywania kopii zapasowych tempdb.
Podczas uruchamiania instancji SQL Server pliki danych i plik dziennika tempdb są inicjalizowane, a baza jest tworzona ponownie na podstawie konfiguracji zapisanej dla instancji. W praktyce oznacza to, że dane istniejące w tempdb przed zatrzymaniem usługi nie są przeznaczone do odtworzenia po kolejnym uruchomieniu. Próba zastosowania instrukcji BACKUP DATABASE tempdb kończy się błędem, ponieważ ta baza ma szczególny status systemowy i nie może być objęta standardowym mechanizmem backupu baz użytkownika.
Różnica między tempdb a bazą przechowującą dane trwałe
W bazie użytkownika kopia zapasowa chroni informacje, które powinny przetrwać awarię usługi, serwera lub nośnika. Dotyczy to tabel, indeksów, schematów, procedur składowanych oraz dziennika transakcji. W przypadku tempdb przechowywane są przede wszystkim obiekty robocze tworzone na czas wykonywania zapytań i transakcji. Ich odtworzenie z backupu nie miałoby wartości, ponieważ po restarcie SQL Server musi rozpocząć pracę z pustym środowiskiem tymczasowym.
Nie należy utożsamiać braku backupu tempdb z brakiem ochrony całej instancji SQL Server. Kopie zapasowe wykonuje się dla baz użytkownika, takich jak bazy aplikacji, oraz dla systemowych baz, dla których SQL Server przewiduje taki mechanizm, między innymi master i msdb. Baza model również może być objęta backupem, ponieważ służy jako wzorzec przy tworzeniu nowych baz. tempdb pozostaje wyjątkiem wynikającym z jej tymczasowego przeznaczenia, a nie z błędnej konfiguracji zadania backupu.
Co dzieje się po restarcie instancji
Po uruchomieniu SQL Server odtwarzane są ustawienia plików tempdb, takie jak ich lokalizacje, nazwy logiczne, rozmiary początkowe i przyrosty zapisane w konfiguracji instancji. Sama zawartość tymczasowych tabel, obiektów roboczych i danych wersjonowania nie jest przywracana. Jeżeli pliki znajdują się na niedostępnym woluminie, mają nieprawidłowe uprawnienia albo ich rozmiar początkowy wymaga większej ilości wolnego miejsca niż jest dostępna, uruchomienie instancji może się nie powieść. Jest to problem konfiguracji lub zasobów, a nie brakującej kopii zapasowej.
Diagnostyka powinna dlatego obejmować komunikaty z dziennika błędów SQL Server, stan usługi, dostępność woluminów, wolne miejsce, uprawnienia konta usługi oraz parametry plików tempdb. Warto także sprawdzić, czy lokalizacje plików zapisane w metadanych instancji odpowiadają rzeczywistym ścieżkom. Do analizy konfiguracji można wykorzystać między innymi zapytania do widoku katalogowego sys.master_files, który pokazuje informacje o plikach baz danych z perspektywy instancji. Takie sprawdzenie nie zastępuje backupu baz użytkownika i nie służy do tworzenia kopii tempdb.
Znaczenie tego ograniczenia w planie odtwarzania
Plan odtwarzania po awarii powinien zakładać ponowne utworzenie pustej bazy tempdb podczas startu SQL Server, a nie jej przywracanie. Ochrona danych aplikacyjnych wymaga regularnych kopii pełnych, różnicowych i dziennika transakcji tam, gdzie pozwala na to model odzyskiwania danej bazy. Po przywróceniu baz użytkownika trzeba dodatkowo zweryfikować połączenia aplikacji, zadania SQL Server Agent, uprawnienia oraz dostępność zasobów potrzebnych do ponownego utworzenia środowiska tymczasowego.
Jeżeli zgłoszenie zawiera komunikat o niedozwolonym backupie tempdb, nie należy obchodzić tego ograniczenia przez zmianę nazwy bazy, kopiowanie jej plików podczas pracy instancji ani dodawanie jej do skryptu obejmującego wszystkie bazy. Takie działania nie tworzą prawidłowej kopii zapasowej i mogą prowadzić do niespójności. Właściwe postępowanie polega na wyłączeniu tempdb z zadania backupu, sprawdzeniu, czy skrypt prawidłowo rozpoznaje bazy systemowe, oraz objęciu ochroną tych baz, których dane mają charakter trwały. Przy analizie problemów z laptopem lub komputerem PC związanych z narzędziami administracyjnymi, dyskami i działaniem systemu można wykonywać diagnostykę środowiska sprzętowego oraz oprogramowania, bez traktowania tempdb jako bazy podlegającej archiwizacji.
