sys.databases zwraca listę wszystkich baz danych dostępnych na instancji wraz z ich właściwościami.
Widok katalogowy instancji SQL Server
sys.databases jest systemowym widokiem katalogowym Microsoft SQL Server. Udostępnia informacje opisujące bazy zarejestrowane na konkretnej instancji, dlatego jego zawartość należy zawsze interpretować w kontekście połączenia, uprawnień oraz aktualnego stanu silnika. Nie jest to tabela przeznaczona do ręcznej modyfikacji. Dane są prezentowane przez mechanizmy SQL Server i mogą odzwierciedlać zmiany wykonane podczas tworzenia, usuwania, odłączania, przyłączania albo zmiany konfiguracji bazy.
Najprostsze odczytanie widoku polega na wykonaniu zapytania SELECT name, database_id, state_desc FROM sys.databases;. Zwrócone wartości pozwalają ustalić, jak baza się nazywa, jaki identyfikator ma w ramach instancji oraz czy znajduje się w stanie umożliwiającym normalną pracę. W praktyce warto wybierać konkretne kolumny zamiast stosować SELECT *, ponieważ widoki systemowe mogą otrzymywać nowe pola wraz z kolejnymi wersjami produktu, a niejawne pobieranie wszystkich danych utrudnia utrzymanie skryptów.
Widok opisuje bazę jako obiekt zarządzany przez SQL Server, a nie jako zwykły folder z plikami. Sama obecność wiersza nie oznacza, że aplikacja może się poprawnie połączyć, że wszystkie pliki są dostępne ani że dane są wolne od błędów. Do oceny sytuacji trzeba zestawić informacje z widoku z komunikatami silnika, stanem nośnika oraz wynikami innych, właściwych kontroli administracyjnych.
Jak czytać najważniejsze właściwości
Kolumny identyfikacyjne, takie jak name i database_id, pomagają odróżnić bazy o podobnych nazwach w różnych środowiskach i jednoznacznie wskazywać obiekt w skryptach. state oraz state_desc informują o stanie bazy, na przykład o gotowości do użycia albo o sytuacji, w której trwa przywracanie, odzyskiwanie lub wystąpił problem z dostępnością. Do raportów dla ludzi wygodniejsza jest forma opisowa, natomiast automatyzacja często korzysta z wartości liczbowych lub warunków porównujących stan.
user_access_desc pokazuje, czy baza przyjmuje połączenia użytkowników w trybie normalnym, ograniczonym lub czy dostęp został wyłączony. To istotne przy diagnozowaniu komunikatu, że baza istnieje, ale aplikacja nie może z niej korzystać. is_read_only pozwala rozpoznać bazę, w której odczyt jest możliwy, lecz operacje zapisu są blokowane na poziomie właściwości bazy. Nie należy mylić tego ustawienia z chwilową blokadą pojedynczej tabeli, transakcją oczekującą na blokadę ani uprawnieniami konkretnego konta.
Właściwości recovery_model i recovery_model_desc opisują model odzyskiwania używany przez SQL Server. Wpływa on na sposób zarządzania dziennikiem transakcji oraz na możliwości planowania kopii zapasowych dziennika. Sama wartość modelu nie potwierdza, że kopie są wykonywane, poprawnie kończą się ani że można z nich odtworzyć oczekiwany punkt w czasie. compatibility_level wskazuje poziom zgodności zachowania bazy z określoną wersją silnika; nie jest prostym odpowiednikiem wersji zainstalowanego SQL Server.
Przydatne bywają również informacje o sortowaniu, dostępie, właścicielu, dacie utworzenia, zamknięciu bazy oraz ustawieniach związanych z zawieraniem. Widoczność części danych zależy od uprawnień konta wykonującego zapytanie. Administrator może więc zobaczyć więcej szczegółów niż zwykły użytkownik aplikacji, a różnica między dwoma wynikami nie musi oznaczać, że katalog zmienił się w międzyczasie.
Diagnozowanie na podstawie wyników
Jeżeli nazwa oczekiwanej bazy nie pojawia się w wyniku, trzeba rozważyć kilka odrębnych przyczyn: połączenie z inną instancją, brak wymaganych uprawnień, usunięcie bazy albo problem z jej dołączeniem. Najpierw należy zweryfikować nazwę instancji i punkt połączenia, a dopiero później analizować aplikację. Sprawdzanie sys.databases na niewłaściwym połączeniu może prowadzić do błędnego wniosku, że baza zniknęła.
Stan OFFLINE, RECOVERING, RESTORING, RECOVERY_PENDING lub SUSPECT wymaga innego postępowania. Każdy z tych stanów opisuje odmienny etap albo rodzaj problemu, dlatego nie powinno się zmieniać go przypadkowym poleceniem znalezionym w internecie. Szczególnie ryzykowne jest wymuszanie dostępu bez ustalenia, czy przyczyną są brakujące pliki, niespójność danych, niedokończone odtwarzanie czy awaria nośnika.
Wyniki widoku można filtrować, aby szybko odszukać bazy niedostępne, tylko do odczytu albo działające w określonym modelu odzyskiwania. Przykładowo zapytanie SELECT name, state_desc, user_access_desc, is_read_only FROM sys.databases WHERE state_desc <> 'ONLINE'; nadaje się do wstępnego raportu kontrolnego. Taki raport nie zastępuje jednak analizy dzienników SQL Server, kopii zapasowych, wolnego miejsca i kondycji systemu plików.
Warto pamiętać, że katalog opisuje stan obserwowany w chwili wykonania zapytania. Po zakończeniu przywracania, zmianie trybu dostępu albo ponownym uruchomieniu instancji wynik może wyglądać inaczej. Skrypty monitorujące powinny więc zapisywać czas odczytu i reagować na zmianę stanu, zamiast traktować pojedynczy wynik jako pełną historię zdarzeń.
Gdzie kończy się diagnoza programowa
Do konsultacji technicznej warto przygotować nazwę instancji, nazwę bazy, wynik wybranych kolumn z sys.databases, dokładny komunikat błędu oraz informację, co zmieniło się przed wystąpieniem problemu. Przydatne są również dane o tym, czy komputer był wyłączany awaryjnie, czy występowały zawieszenia, restarty, błędy odczytu plików albo problemy z uruchamianiem systemu. Takie informacje pomagają oddzielić błąd konfiguracji SQL Server od problemu z komputerem, na którym przechowywane są pliki.
Jeżeli baza przestała być dostępna po objawach wskazujących na uszkodzenie dysku, niestabilne zasilanie, przegrzewanie, awarię pamięci lub problemy z płytą główną, dalsze próby zapisu mogą pogorszyć sytuację. W pierwszej kolejności należy zabezpieczyć nośnik i kopie danych, a następnie ustalić, czy komputer działa stabilnie. Odtwarzanie bazy bez sprawnego źródła plików albo bez poprawnej kopii zapasowej nie rozwiązuje fizycznej przyczyny awarii.
Warszawskie Pogotowie Komputerowe podejmuje się fizycznej naprawy laptopów i komputerów stacjonarnych wraz z podzespołami.
W przypadku podejrzenia awarii sprzętu warto przerwać eksperymenty z wymuszaniem trybu online, zmianą właściciela lub przebudową konfiguracji. Najpierw trzeba ocenić, czy nośnik jest czytelny i czy dane można bezpiecznie skopiować. Dopiero po zabezpieczeniu materiału można wrócić do analizy SQL Server, sprawdzenia kopii zapasowych i planowania właściwego odtworzenia bazy.
