Serwisanci dostępni teraz · czynne całą dobę, także w weekendy i świętaWarszawa i okolice · dojazd bezpłatny
Darmowa diagnoza laptopa
Darmowa diagnoza laptopa
Dojazd do klienta bezpłatnie
Dojazd do klienta bezpłatnie
Laptopy zastępcze bezpłatnie
Laptopy zastępcze bezpłatnie
Odbiór i zwrot sprzętu bezpłatnie
Odbiór i zwrot sprzętu bezpłatnie

master

Termin Definicja
master

master to baza systemowa SQL Server przechowująca konfigurację instancji i informacje o pozostałych bazach.

Rola bazy master w instancji SQL Server

master jest systemową bazą danych programu Microsoft SQL Server. Każda instancja silnika korzysta z własnej bazy master, ponieważ przechowuje ona informacje potrzebne do uruchomienia instancji oraz do rozpoznania jej podstawowej konfiguracji. W bazie znajdują się między innymi metadane dotyczące baz użytkownika, baz systemowych, logowań, endpointów, ustawień konfiguracji oraz części obiektów serwerowych. Nie jest to baza przeznaczona do przechowywania tabel aplikacji biznesowych.

SQL Server odczytuje bazę master podczas startu usługi. Zawarte w niej informacje pomagają silnikowi ustalić, jakie bazy danych należą do instancji, gdzie znajdują się ich pliki oraz jakie obiekty i konta są dostępne na poziomie serwera. W katalogu systemowym można znaleźć między innymi widoki i procedury związane z metadanymi instancji, choć dokładny zakres obiektów może zależeć od wersji SQL Server i zainstalowanych składników. Uszkodzenie albo brak dostępu do master może więc uniemożliwić normalne uruchomienie silnika, nawet jeśli pliki baz użytkownika pozostają nieuszkodzone.

Jakie informacje SQL Server wiąże z bazą master

Baza master zawiera katalog instancji, a nie pełną zawartość wszystkich pozostałych baz. SQL Server zapisuje w niej między innymi informacje o bazach danych widocznych dla danej instancji, ich identyfikatorach, stanie, trybie dostępu i lokalizacji plików. W praktyce administrator może obserwować te dane przez widoki katalogowe, takie jak sys.databases oraz sys.master_files. Widok sys.databases opisuje bazy z perspektywy instancji, natomiast sys.master_files udostępnia informacje o plikach baz zarejestrowanych w instancji.

Na poziomie instancji master przechowuje również dane dotyczące logowań i części ustawień serwerowych. Przykładem jest widok sys.server_principals, który pokazuje podmioty zabezpieczeń zdefiniowane dla serwera, w tym logowania SQL Server i logowania oparte na mechanizmach systemu Windows. W master mogą być także zarejestrowane endpointy używane przez usługi SQL Server oraz definicje serwerowych wyzwalaczy, poświadczeń i innych obiektów zależnych od konfiguracji instancji. Uprawnienia do odczytu tych informacji są kontrolowane przez model zabezpieczeń SQL Server, dlatego zwykły użytkownik nie musi widzieć pełnego katalogu instancji.

Nie wszystkie dane administracyjne dotyczące konkretnej bazy znajdują się w master. Każda baza użytkownika ma własny katalog systemowy, w którym przechowywane są informacje o jej tabelach, indeksach, schematach, użytkownikach i obiektach. Master wskazuje między innymi, że dana baza istnieje i jak silnik ma ją odnaleźć, ale definicje obiektów znajdujących się wewnątrz tej bazy są przechowywane przede wszystkim w jej własnych strukturach systemowych. To rozróżnienie ma znaczenie podczas diagnozowania awarii oraz planowania odtwarzania.

Uruchamianie, kopia zapasowa i odtwarzanie master

Master jest bazą krytyczną dla instancji, dlatego powinna być objęta regularnym planem kopii zapasowych. Kopię można wykonać standardowym poleceniem języka Transact-SQL, na przykład BACKUP DATABASE master TO DISK = 'D:\Backup\master.bak' WITH INIT, po dostosowaniu ścieżki do rzeczywistej konfiguracji. Polecenie musi być uruchomione w kontekście instancji SQL Server przez konto mające uprawnienia wymagane do wykonania kopii. Plik kopii powinien być przechowywany poza woluminem, którego awaria mogłaby jednocześnie zniszczyć bazę i jej kopię.

W przypadku master zwykle wykonuje się kopie pełne. Ta baza nie obsługuje modelu odzyskiwania w taki sam sposób jak typowa baza aplikacyjna, a po odtworzeniu konieczne może być ponowne wykonanie zmian wprowadzonych po utworzeniu kopii, takich jak nowe logowania, zmiany konfiguracji instancji, definicje endpointów lub informacje o nowych bazach. Odtwarzanie master wymaga odpowiedniej procedury serwisowej i uruchomienia SQL Server w trybie umożliwiającym wykonanie operacji naprawczej. Po przywróceniu trzeba sprawdzić dostępność pozostałych baz, poprawność ścieżek plików oraz zgodność konfiguracji z aktualnym stanem środowiska.

Jeżeli master jest uszkodzona, diagnostykę rozpoczyna się od dziennika błędów SQL Server, komunikatów usługi oraz sprawdzenia lokalizacji plików bazy. Pomocne są także narzędzia systemowe i konfiguracja usługi SQL Server, ponieważ silnik musi mieć dostęp do pliku danych i pliku dziennika master. Nie należy usuwać ani ręcznie podmieniać tych plików bez przygotowanej procedury i kopii awaryjnej. Próba odtworzenia wyłącznie plików baz użytkownika nie przywraca automatycznie metadanych instancji zapisanych w master.

Znaczenie master podczas diagnostyki instancji

Problemy z master mogą objawiać się inaczej niż awaria pojedynczej bazy aplikacyjnej. Jeżeli SQL Server nie może odczytać master, usługa może nie wystartować, a połączenia klientów będą odrzucane jeszcze przed wyborem konkretnej bazy. Gdy instancja uruchamia się poprawnie, ale nie pokazuje oczekiwanej bazy, warto porównać wpisy w sys.databases z rzeczywistą lokalizacją plików i stanem plików MDF oraz LDF. Komunikat o bazie w stanie OFFLINE, RECOVERY_PENDING lub SUSPECT oznacza inną sytuację niż całkowity brak rejestracji bazy w katalogu instancji.

W diagnostyce należy rozdzielić trzy warstwy: dostępność usługi SQL Server, poprawność katalogu instancji przechowywanego w master oraz stan konkretnej bazy użytkownika. Najpierw sprawdza się, czy usługa działa i czy log błędów nie wskazuje na problemy z plikami systemowymi. Następnie analizuje się metadane instancji, logowania i konfigurację ścieżek. Dopiero później ocenia się integralność bazy aplikacyjnej, jej dziennika transakcji oraz zależności między obiektami. Taka kolejność ogranicza ryzyko błędnego przypisania problemu z połączeniem do tabel lub danych aplikacji.

W środowisku produkcyjnym warto dokumentować lokalizację plików master, harmonogram kopii, właścicieli procedury odtwarzania oraz sposób weryfikacji po awarii. Należy też sprawdzać, czy kopia zapasowa rzeczywiście powstała i czy można ją odczytać w kontrolowanym teście. Master nie zawiera całej zawartości baz użytkownika, ale jej stan wpływa na możliwość rozpoznania i obsługi całej instancji SQL Server. Dlatego jej ochrona, monitorowanie oraz odtwarzanie powinny być traktowane jako osobny element utrzymania silnika baz danych.

+48 22 100 48 29Zadzwoń teraz · serwisant w 1 godzinę