Kompatybilność baz systemowych

Kompatybilność baz systemowych dotyczy zgodności wewnętrznych baz SQL Server z wersją zainstalowanego silnika.

Na czym polega kompatybilność baz systemowych w SQL Server

Kompatybilność baz systemowych w środowisku SQL Server oznacza zgodność baz wymaganych przez silnik z wersją uruchomionego produktu oraz z jego wewnętrznymi mechanizmami zarządzania. Do baz systemowych SQL Server należą między innymi master, model, msdb i tempdb. Przechowują one konfigurację instancji, informacje o bazach, zadania agenta, harmonogramy, historię operacji, metadane oraz obiekty wykorzystywane podczas wykonywania zapytań. Ich poprawne działanie jest warunkiem uruchomienia instancji i prawidłowej obsługi baz użytkownika.

Nie należy utożsamiać zgodności bazy systemowej z poziomem zgodności bazy użytkownika. W SQL Server właściwość compatibility_level określa przede wszystkim sposób interpretowania części zapytań i zachowanie optymalizatora dla danej bazy. Bazy systemowe są natomiast częścią konkretnej instalacji silnika i są aktualizowane przez proces instalacyjny lub przez procedurę aktualizacji instancji. Zgodność obejmuje więc strukturę metadanych, dostępne obiekty systemowe, wersję plików oraz zależności między komponentami silnika.

Różnica między wersją silnika a poziomem zgodności

SQL Server może uruchamiać bazę użytkownika utworzoną w starszej wersji produktu, o ile spełnione są wymagania dotyczące ścieżki aktualizacji i funkcji używanych przez tę bazę. Poziom zgodności pozwala zachować część wcześniejszych zachowań języka T-SQL i optymalizatora podczas migracji. Nie jest on jednak osobnym silnikiem ani pełnym trybem emulacji starszej wersji SQL Server. Podniesienie poziomu zgodności może zmienić plan wykonania zapytań, sposób rozwiązywania niektórych konstrukcji językowych oraz działanie wybranych funkcji.

Stan instancji można oceniać, porównując wersję serwera zwracaną przez SERVERPROPERTY('ProductVersion') z metadanymi baz zapisanymi w katalogu systemowym. Poziom zgodności poszczególnych baz można odczytać zapytaniem:

SELECT name, compatibility_level FROM sys.databases;

Wartość poziomu zgodności jest liczbą przypisaną do konkretnej generacji SQL Server, dlatego interpretacja tej liczby musi uwzględniać dokumentację używanej wersji produktu. Sama wartość nie informuje, że pliki bazy systemowej pochodzą z tej samej wersji co silnik. Przy analizie należy osobno sprawdzić wersję instancji, stan baz systemowych, historię aktualizacji oraz ewentualne komunikaty zapisane w dzienniku SQL Server i w dzienniku systemowym.

Objawy niezgodności podczas uruchamiania instancji

Problem z kompatybilnością może ujawnić się podczas startu usługi SQL Server, aktualizacji instancji, odtwarzania bazy systemowej albo pracy narzędzi korzystających z metadanych silnika. Typowymi sygnałami są błędy otwierania bazy master, model, msdb lub tempdb, niepowodzenie przejścia bazy do stanu online, komunikaty o niezgodnej wersji pliku oraz brak oczekiwanych obiektów systemowych. W przypadku master problem może uniemożliwić normalne uruchomienie instancji, ponieważ ta baza zawiera podstawowe informacje potrzebne do załadowania konfiguracji i lokalizacji pozostałych baz.

Odrębną klasę problemów stanowią błędy wynikające z użycia elementu usuniętego, zmienionego albo niedostępnego w danej wersji SQL Server. Dotyczy to między innymi nieaktualnych procedur systemowych, rozszerzeń języka, ustawień konfiguracyjnych oraz skryptów instalacyjnych zakładających inną strukturę katalogu systemowego. Samo obniżenie poziomu zgodności bazy użytkownika nie przywraca brakujących obiektów w bazach systemowych i nie naprawia niezgodnych plików.

Diagnostyka powinna obejmować odczyt komunikatów startowych, sprawdzenie katalogu błędów SQL Server, weryfikację ścieżek plików baz oraz porównanie stanu wszystkich baz w widoku sys.databases. Istotne jest również ustalenie, czy problem pojawił się po aktualizacji, przeniesieniu plików, ręcznej podmianie bazy, odtworzeniu kopii zapasowej lub zmianie konta usługi. Takie zdarzenia mogą wskazywać na niespójność wersji, uprawnień albo konfiguracji, a nie na błąd samego zapytania użytkownika.

Bezpieczna weryfikacja i przywracanie zgodności

Zmiany dotyczące baz systemowych powinny być wykonywane zgodnie z procedurą właściwą dla używanej wersji SQL Server. Przed ingerencją należy zabezpieczyć kopie zapasowe baz użytkownika, zapisać konfigurację instancji i ustalić położenie plików. Bazy master, model i msdb mają odmienną rolę, dlatego nie można traktować ich jak zwykłych baz aplikacyjnych. W szczególności ręczne kopiowanie plików między różnymi wersjami silnika może doprowadzić do kolejnych błędów i utraty dostępu do konfiguracji.

Po aktualizacji SQL Server instalator wykonuje operacje dostosowujące elementy systemowe do nowej wersji. Jeżeli aktualizacja została przerwana, należy najpierw przeanalizować jej logi oraz komunikaty silnika, a dopiero potem wybierać procedurę naprawczą. W zależności od przyczyny może być potrzebna ponowna konfiguracja instancji, odtworzenie określonej bazy systemowej, uruchomienie narzędzi serwisowych albo migracja danych do nowej instancji. Każde takie działanie powinno uwzględniać zależności między bazami, zadaniami SQL Server Agent, operatorami, alertami, logowaniami i ustawieniami instancji.

W środowisku z laptopem lub komputerem PC problem związany z SQL Server wymaga najpierw rozdzielenia awarii samego systemu Windows, uszkodzenia nośnika, błędu usługi oraz niezgodności składników bazy danych. Diagnostyka techniczna powinna potwierdzić wersję SQL Server, stan baz, dostępność plików i treść komunikatów, zanim zostanie podjęta próba naprawy lub migracji. Takie uporządkowanie pozwala ograniczyć ryzyko nadpisania aktualnych plików i odróżnić problem kompatybilności od zwykłej awarii konfiguracji.