Baza danych systemowa to jedna z wewnętrznych baz wymaganych do działania instancji SQL Server, takich jak master czy msdb.
Rola baz systemowych w SQL Server
Baza danych systemowa to wewnętrzna baza wymagana do działania instancji Microsoft SQL Server. Nie przechowuje ona danych aplikacji w taki sposób jak baza utworzona dla sklepu internetowego, programu księgowego czy systemu magazynowego. Zawiera natomiast informacje potrzebne silnikowi do uruchamiania instancji, zarządzania zadaniami, obsługi konfiguracji, harmonogramów, historii operacji oraz tworzenia środowiska dla innych baz. Do podstawowego zestawu baz systemowych należą master, model, msdb i tempdb.
Baza master przechowuje między innymi informacje o bazach danych należących do instancji, logowaniach, punktach końcowych, konfiguracji oraz ustawieniach systemowych. Bez poprawnie działającej bazy master SQL Server nie może prawidłowo odczytać podstawowej konfiguracji instancji. Baza model pełni funkcję wzorca używanego podczas tworzenia nowych baz danych. Jej ustawienia i obiekty mogą wpływać na początkową strukturę nowo utworzonej bazy, dlatego nie jest wyłącznie biernym magazynem technicznym.
Master, msdb, model i tempdb — różne zadania
msdb służy przede wszystkim do przechowywania danych związanych z SQL Server Agent, zadaniami, harmonogramami, operatorami, alertami i historią wykonywania zadań. W tej bazie mogą znajdować się również informacje używane przez inne składniki SQL Server, między innymi przez mechanizmy kopii zapasowych, Maintenance Plans oraz Database Mail. Uszkodzenie lub utrata części danych msdb może więc spowodować zniknięcie harmonogramów, historii zadań albo konfiguracji automatycznych operacji.
tempdb jest bazą roboczą odtwarzaną podczas każdego uruchomienia instancji. Silnik wykorzystuje ją między innymi do tabel tymczasowych, zmiennych tabelarycznych, wyników pośrednich, sortowania, operacji agregacji oraz niektórych mechanizmów kontroli wersji wierszy. Dane przechowywane w tempdb nie są przeznaczone do trwałego przechowywania po restarcie usługi. Problemy z miejscem na dysku, plikami danych lub plikiem dziennika transakcji tempdb mogą jednak zatrzymać zapytania i uniemożliwić wykonywanie operacji wymagających przestrzeni roboczej.
Uruchamianie instancji i zależności techniczne
Podczas startu instancji SQL Server silnik musi uzyskać dostęp do plików i metadanych baz systemowych. Szczególne znaczenie ma master, ponieważ znajdują się w niej informacje pozwalające odnaleźć pozostałe bazy oraz odczytać konfigurację instancji. Jeżeli pliki bazy zostały przeniesione bez aktualizacji konfiguracji, usunięte, zablokowane przez system plików albo znajdują się na niedostępnym woluminie, usługa może nie uruchomić się prawidłowo. W takiej sytuacji sam dostęp do plików baz użytkownika nie wystarcza do przywrócenia działania silnika.
Diagnoza problemu obejmuje analizę dziennika błędów SQL Server, Podglądu zdarzeń systemu Windows, statusu usługi, parametrów uruchomieniowych oraz dostępności woluminów zawierających pliki .mdf, .ndf i .ldf. Należy rozróżnić awarię samej usługi od uszkodzenia konkretnej bazy systemowej. Komunikat o braku pliku, błędzie uprawnień, niezgodności ścieżki lub niemożności odtworzenia bazy wskazuje na inną przyczynę i wymaga innego postępowania. Nie należy pochopnie tworzyć pustej bazy o takiej samej nazwie, ponieważ nie odtworzy to wymaganych metadanych ani konfiguracji instancji.
Ochrona, kopie zapasowe i bezpieczna naprawa
Bazy systemowe wymagają ochrony podobnej do innych ważnych baz, choć sposób postępowania zależy od konkretnej bazy. Kopie zapasowe master pozwalają zachować między innymi konfigurację instancji i informacje o logowaniach. Kopie msdb są istotne dla odtworzenia zadań SQL Server Agent, harmonogramów, historii oraz wybranych ustawień automatyzacji. Baza model może wymagać kopii, gdy zawiera celowo zmodyfikowany wzorzec dla nowych baz. tempdb nie jest archiwizowana w zwykłym sensie, ponieważ po restarcie jest tworzona ponownie.
Naprawa problemu z bazą systemową powinna rozpocząć się od zabezpieczenia dostępnych plików i kopii zapasowych oraz ustalenia, czy problem dotyczy nośnika, systemu plików, uprawnień, konfiguracji ścieżek, czy logicznej spójności bazy. Operacje takie jak odtwarzanie master, odbudowa baz systemowych lub uruchamianie procedur naprawczych mogą zmienić stan całej instancji, dlatego wymagają zgodności z używaną edycją i wersją SQL Server oraz dokładnego planu. Przy diagnostyce komputera, na którym działa lokalna instancja SQL Server, trzeba sprawdzić również stan dysku, wolne miejsce, błędy kontrolera pamięci masowej i ciągłość zasilania. Pozwala to odróżnić awarię oprogramowania bazodanowego od problemu sprzętowego powodującego uszkadzanie plików.
