Kolumna state_desc w sys.databases opisuje bieżący stan bazy, np. ONLINE, RESTORING czy SUSPECT.
Widok sys.databases i znaczenie state_desc
Widok sys.databases jest systemowym źródłem informacji o bazach danych dostępnych w danej instancji Microsoft SQL Server. Znajdują się w nim zarówno bazy użytkownika, jak i bazy systemowe, a każda z nich jest opisana zestawem kolumn dotyczących między innymi nazwy, identyfikatora, modelu odzyskiwania, poziomu zgodności, opcji bezpieczeństwa oraz bieżącego stanu. Kolumna state_desc przedstawia ten stan w formie czytelnego tekstu, dzięki czemu łatwiej ocenić, czy baza może normalnie przyjmować połączenia i realizować operacje.
Warto rozróżnić state_desc od kolumny state. Pierwsza zwraca nazwę opisową, taką jak ONLINE, OFFLINE, RESTORING albo SUSPECT. Druga przechowuje odpowiadającą jej wartość liczbową. W codziennej diagnostyce użycie state_desc jest zwykle wygodniejsze, ponieważ wynik można odczytać bez dodatkowej tabeli mapującej liczby na znaczenia. Przykładowe zapytanie może wyglądać następująco:
SELECT name, state_desc FROM sys.databases ORDER BY name;
Taki odczyt pozwala szybko uzyskać listę baz i sprawdzić, czy któraś z nich pozostaje w stanie innym niż oczekiwany. Sam status nie wyjaśnia jednak pełnej przyczyny problemu. Informuje o rezultacie obserwowanym przez system, ale do ustalenia źródła nieprawidłowości potrzebne są również komunikaty, historia operacji, informacje o plikach oraz kontekst wykonywanych czynności.
State_desc w sys.databases na tle innych informacji
Wynik state_desc należy traktować jako syntetyczny opis dostępności bazy, a nie jako kompletny raport diagnostyczny. Status ONLINE oznacza, że baza jest otwarta i zasadniczo dostępna dla zwykłej pracy. Nie gwarantuje jednak, że każda tabela, każdy indeks czy każda aplikacja działa prawidłowo. Możliwe są problemy z uprawnieniami, spójnością danych, wydajnością zapytań, miejscem na dysku albo połączeniem z programem korzystającym z bazy.
Stan OFFLINE wskazuje, że baza została wyłączona z normalnej dostępności. Może to być działanie zaplanowane, element procedury serwisowej albo skutek decyzji podjętej w celu ograniczenia dostępu do danych. RESTORING wiąże się z trwającym odtwarzaniem lub przygotowaniem bazy do kolejnego etapu odtwarzania. W tym stanie próba korzystania z bazy tak, jakby była gotowa do pracy, może prowadzić do błędów po stronie aplikacji.
Stan RECOVERING oznacza etap przywracania bazy do spójnego działania po określonym zdarzeniu. Przy RECOVERY_PENDING system wie, że odzyskiwanie powinno się rozpocząć, ale napotkał przeszkodę uniemożliwiającą jego prawidłowe uruchomienie. SUSPECT jest sygnałem poważniejszej nieprawidłowości: baza nie została pomyślnie otwarta albo proces odzyskiwania nie zakończył się poprawnie. W takim przypadku pochopne działania mogą utrudnić późniejsze odtworzenie danych.
Niektóre stany są związane z trybami ograniczonego dostępu. RESTRICTED_USER pozwala na pracę tylko określonej grupie użytkowników, natomiast EMERGENCY służy do podejmowania działań awaryjnych w sytuacji, gdy zwykły sposób otwarcia bazy nie działa. Znaczenie stanu trzeba zawsze odczytywać razem z tym, co było wykonywane wcześniej. Ten sam wpis w state_desc może wymagać innej reakcji podczas planowanego odtwarzania, a innej po nagłym zaniku zasilania lub błędzie nośnika.
Typowe problemy ujawniane przez sys.databases state_desc
Jednym z częstszych przypadków jest zauważenie, że baza pozostaje w stanie RESTORING dłużej, niż przewidywała procedura. Przyczyną może być nieukończony zestaw kopii, oczekiwanie na kolejny plik dziennika transakcji albo świadome pozostawienie bazy niedostępnej do czasu zastosowania następnego etapu. Samo wymuszenie zmiany stanu bez sprawdzenia kolejności kopii może przerwać poprawny proces odzyskiwania.
Inny scenariusz dotyczy RECOVERY_PENDING. Wtedy trzeba sprawdzić, czy dostępne są pliki danych i dziennika, czy ścieżki do nich są prawidłowe oraz czy system ma możliwość odczytu i zapisu w wymaganych lokalizacjach. Znaczenie mogą mieć także błędy urządzenia, brak wolnego miejsca, zmienione uprawnienia albo uszkodzenie struktury pliku. Warto zebrać komunikaty z dziennika systemowego i dziennika SQL Server, ponieważ wpis w sys.databases jest tylko punktem wyjścia.
Przy stanie SUSPECT nie zaleca się wykonywania przypadkowych poleceń znalezionych w krótkich poradnikach. Próba naprawy bez kopii i bez rozpoznania sytuacji może spowodować utratę części danych albo nadpisać informacje potrzebne do analizy. W pierwszej kolejności powinno się ustalić, czy istnieje aktualna kopia zapasowa, kiedy pojawił się problem, jakie operacje były wykonywane przed jego wystąpieniem oraz czy inne bazy działają prawidłowo.
Czasem alarm wynika z nieporozumienia dotyczącego zakresu widoku. sys.databases pokazuje stan bazy, ale nie opisuje bezpośrednio stanu pojedynczej tabeli, indeksu, zadania automatycznego ani konkretnego połączenia aplikacyjnego. Gdy state_desc ma wartość ONLINE, a użytkownicy nadal zgłaszają błędy, trzeba sprawdzić również logowanie, mapowanie użytkowników, blokady, limity zasobów, błędy zapytań oraz działanie samej aplikacji.
Praktyczne wskazówki dla odczytu state_desc
Najprostsze zapytanie warto rozszerzyć o kolumny pomagające zidentyfikować bazę i ocenić jej konfigurację:
SELECT database_id, name, state, state_desc, recovery_model_desc, compatibility_level FROM sys.databases ORDER BY database_id;
database_id pomaga odróżnić bazy o podobnych nazwach, recovery_model_desc pokazuje wybrany model odzyskiwania, a compatibility_level wskazuje poziom zgodności używany przy interpretacji części zachowań silnika. Te wartości nie zastępują pełnego audytu, ale ułatwiają przygotowanie pierwszego obrazu sytuacji. Przy analizie można także zapisać wynik z kilku chwil, aby sprawdzić, czy stan się zmienia, czy pozostaje stały.
Przydatne jest filtrowanie baz wymagających uwagi:
SELECT name, state_desc FROM sys.databases WHERE state_desc <> 'ONLINE';
Takie polecenie szybko wyłapuje pozycje odbiegające od typowego stanu pracy. Nie powinno się jednak zakładać, że każda wartość różna od ONLINE oznacza awarię. Baza może być celowo wyłączona, czasowo odtwarzana albo używana w kontrolowanym trybie ograniczonego dostępu. Ocenę należy połączyć z dokumentacją procedury, godziną rozpoczęcia operacji i komunikatami zapisanymi przez system.
Podczas zbierania informacji należy unikać zmiany konfiguracji wyłącznie po to, aby zniknął niepokojący wpis. Bezpieczniejsza kolejność obejmuje odczyt aktualnego stanu, zachowanie komunikatów, sprawdzenie dostępności kopii zapasowych, potwierdzenie miejsca na nośnikach i dopiero późniejsze planowanie działania naprawczego. Jeżeli baza zawiera ważne dane, każda ingerencja powinna być odwracalna albo poprzedzona potwierdzeniem, że możliwe jest odtworzenie danych.
Kiedy zgłosić się z problemem sys.databases state_desc
Pomoc techniczna jest wskazana, gdy status state_desc pozostaje inny niż oczekiwany mimo zakończenia zaplanowanej operacji, gdy baza przechodzi do SUSPECT lub RECOVERY_PENDING, a także wtedy, gdy użytkownicy nie mogą pracować mimo pozornie prawidłowego stanu ONLINE. W zgłoszeniu warto przekazać nazwę bazy, odczytaną wartość state_desc, przybliżony moment pojawienia się problemu, ostatnio wykonywane czynności oraz dostępne komunikaty błędów. Tak przygotowane informacje skracają etap rozpoznania i ograniczają ryzyko przypadkowego uszkodzenia danych.
W przypadku problemów z komputerem, na którym występuje opisywana usterka, można skontaktować się z Warszawskim Pogotowiem Komputerowym 24/7 pod numerem +48 22 100 48 29. Przed przekazaniem sprzętu warto zabezpieczyć kopie ważnych plików, nie usuwać dzienników błędów i nie uruchamiać niesprawdzonych programów naprawczych. Odczyt state_desc jest cenną wskazówką, lecz prawidłowa diagnoza wymaga spojrzenia na cały przebieg zdarzenia, stan nośników, dostępność kopii oraz sposób, w jaki aplikacja korzysta z bazy.
