Bazy systemowe w Microsoft SQL Server to specjalne bazy danych, które są integralną częścią systemu zarządzania bazą danych SQL Server. Są one używane do przechowywania kluczowych informacji dotyczących samego systemu oraz jego konfiguracji.
Bazy Systemowe w Microsoft SQL Server
Istnieje kilka głównych baz systemowych w SQL Server, z których każda pełni określoną rolę.
- Master – główna baza systemowa, która przechowuje informacje o wszystkich bazach danych utworzonych w systemie, logikę systemową oraz konfiguracje samego SQL Server,
- Model – baza zawierająca szablon, który jest używany do tworzenia nowych baz danych. Gdy tworzona jest nowa danych, SQL Server kopiuję strukturę z modelu,
- Msdb – baza danych służąca do przechowywania informacji o planach zadań, operatorach, historii backupu, integracji usług SQL Server (SSIS) i innych elementów zarządzania,
- Tempdb – specjalna baza danych, która służy do przechowywania tymczasowych danych, takich jak tymczasowe tabele i zmienne.
Backup jest możliwy tylko dla trzech rodzajów baz: master, model oraz msdb.
Backup baz systemowych
Backup wszystkich baz na serwerze
W przypadku wybrania tej opcji, automatycznie nie będą uwzględniane wszystkie bazy systemowe w zadaniu. Konieczne będzie ich osobne wybranie.
Backup kopii bazy systemowej
Zadanie backupu należy tworzyć dla bazy systemowej, znajdującej się w katalogu baz systemowych – System Databases.
Jeżeli zostanie utworzone zadanie backupu dla kopii bazy systemowej, umieszczonej w katalogu baz użytkownika – Database Snapshots, aplikacja IBARD nie zidentyfikuje jej jako bazy systemowej, co może skutkować potencjalnymi niezgodnościami lub błędami.
Przywracanie baz systemowych
Zagrożenia
Przywracanie bazy systemowej z backupu wymaga ostrożności i proces powinien być wykonywany w ostateczności, ponieważ niesie za sobą potencjalne zagrożenia i konsekwencje. Oto kilka potencjalnych problemów związanych z przywracaniem bazy systemowej z backupu:
- utrata danych – przywracanie bazy systemowej z backupu może prowadzić do utraty wszelkich zmian i danych wprowadzonych od czasu wykonania tego backupu. Jeśli backup nie jest wystarczająco świeży, może dojść do utraty ważnych informacji,
- naruszenie zabezpieczeń – baza systemowa zawiera informacje o kontach, uprawnieniach i konfiguracjach zabezpieczeń. Przywracając starszy backup, istnieje ryzyko naruszenia aktualnych zabezpieczeń systemu,
- problemy zgodności – jeśli baza systemowa była zaktualizowana wraz z nową wersją SQL Server, przywrócenie z backupu z wcześniejszą wersją może prowadzić do problemów zgodności i błędów,
- przerwy w dostępie – przywracanie bazy systemowej może wymagać zatrzymania usług SQL Server, co prowadzi do przerw w dostępie do bazy danych. Dla niektórych systemów to może być niedopuszczalne,
- błędy w procesie przywracania – sam proces przywracania z backupu może być podatny na błędy ludzkie, takie jak wybranie niewłaściwego backupu, błędy konfiguracyjne lub problemy techniczne.
Specyfika przywracania
Bazy systemowe są przechowywane w swoich dedykowanych podkatalogach, co zapewnia im unikalność. Nie zaleca się przywracania baz systemowych pod inną nazwą. Przywracanie bazy master pod inną nazwą niż oryginalna może skutkować umieszczeniem jej w miejscu przeznaczonym dla baz użytkownika – Database Snapshots. Dla baz model i msdb problem nie występuje, aczkolwiek i tak jest to praktyka niezalecana.
Po przywróceniu backupu bazy na serwer, zawsze wykonywana jest kwerenda „checkdb” (weryfikacja bazy), która dla bazy master spoza katalogu „System Databases” zwróci błąd, sytuacja ta wynika z unikalnej struktury bazy master.
Kwerenda „checkdb” nie zgłosi błędu, gdy baza master zostanie przywrócona w to samo miejsce pod oryginalną nazwą. Warto zaznaczyć, że przywracanie bazy master w tym samym miejscu i nazwie nadpisuje istniejącą, co może prowadzić do potencjalnych problemów opisanych wyżej.
