Brak możliwości uruchomienia bazy

Brak możliwości uruchomienia bazy sygnalizuje niepowodzenie procesu udostępnienia bazy danych przez silnik SQL Server.

Co oznacza brak możliwości uruchomienia bazy w SQL Server

Brak możliwości uruchomienia bazy w Microsoft SQL Server oznacza, że silnik nie doprowadził bazy do stanu ONLINE. Baza może pozostawać w stanie RECOVERY_PENDING, gdy SQL Server wie, że potrzebne jest odzyskiwanie, ale nie może go rozpocząć, albo w stanie RECOVERING, gdy odzyskiwanie już trwa. Inne możliwe stany to RESTORING po rozpoczęciu odtwarzania kopii zapasowej, SUSPECT po wykryciu problemu podczas odzyskiwania oraz EMERGENCY po ręcznym przełączeniu bazy do trybu awaryjnego. Stan OFFLINE oznacza natomiast, że baza została wyłączona administracyjnie.

Uruchomienie bazy nie jest wyłącznie odczytem jednego pliku. SQL Server musi otworzyć plik danych MDF lub NDF oraz plik dziennika transakcji LDF, sprawdzić ich nagłówki, odtworzyć wymagane zmiany zapisane w dzienniku i zapewnić spójność struktur systemowych. Jeżeli brakuje pliku, ścieżka jest niedostępna, plik jest zablokowany albo dziennik nie pozwala na zakończenie procedury odzyskiwania, baza nie przechodzi do normalnej pracy. Sam komunikat o nieuruchomieniu bazy wskazuje skutek, a nie zawsze dokładną przyczynę.

Pliki MDF, NDF i LDF oraz dostęp do ścieżek

Jedną z częstych przyczyn jest brak dostępu do pliku wskazanego w metadanych bazy. SQL Server przechowuje lokalizacje plików w katalogu systemowym i podczas uruchamiania próbuje użyć dokładnie tych ścieżek. Przeniesienie pliku MDF, NDF albo LDF bez wykonania odpowiedniej operacji w SQL Server może spowodować błąd otwarcia bazy. Problem występuje również wtedy, gdy wolumin został odłączony, zmieniła się litera dysku, udział sieciowy nie jest dostępny albo konto usługi SQL Server nie ma uprawnień do odczytu i zapisu w katalogu.

W diagnostyce należy odróżnić brak pliku od odmowy dostępu. Do sprawdzenia lokalizacji plików można wykorzystać zapytanie sys.master_files, przykładowo: SELECT DB_NAME(database_id), name, physical_name, state_desc FROM sys.master_files;. Informacje o bazach i ich stanie pokazuje także sys.databases. Nie należy jednak zakładać, że ręczne nadanie szerokich uprawnień, zmiana właściciela pliku lub kopiowanie plików w czasie pracy silnika rozwiąże problem. Takie działania mogą utrudnić ustalenie pierwotnej przyczyny, a kopiowanie pliku danych bez spójnego mechanizmu kopii zapasowej nie jest prawidłową metodą zabezpieczenia bazy.

Odzyskiwanie transakcji, dziennik i komunikaty błędów

Po nieoczekiwanym zatrzymaniu usługi SQL Server wykonuje odzyskiwanie bazy. Procedura obejmuje fazę analizy, ponowne wykonanie zatwierdzonych operacji oraz wycofanie transakcji, które nie zostały zatwierdzone. Czas trwania zależy między innymi od liczby zmian oczekujących w dzienniku, wydajności magazynu danych i dostępności miejsca. Przerwanie procesu przez kolejne restarty usługi nie usuwa problemu i może rozpocząć odzyskiwanie ponownie.

Jeżeli plik LDF jest uszkodzony, niedostępny albo wolumin nie ma wolnego miejsca, SQL Server może nie zakończyć odzyskiwania. Znaczenie mają też błędy wejścia-wyjścia, problemy kontrolera dysku, awaria systemu plików oraz niespójność stron danych. Najważniejszym źródłem informacji jest dziennik błędów SQL Server, a nie wyłącznie komunikat aplikacji. Warto przeanalizować wpisy dotyczące konkretnej nazwy bazy, numeru błędu, ścieżki pliku, kodu błędu systemu Windows i kolejności zdarzeń. Należy również sprawdzić Podgląd zdarzeń systemu Windows oraz stan woluminów. Próby użycia poleceń naprawczych, w tym DBCC CHECKDB z opcją naprawy, powinny być poprzedzone oceną kopii zapasowych, ponieważ naprawa może usuwać uszkodzone elementy i prowadzić do utraty części danych.

Bezpieczna kolejność postępowania diagnostycznego

Najpierw trzeba ustalić, czy problem dotyczy jednej bazy, czy całej instancji SQL Server. Jeżeli usługa nie działa, należy sprawdzić jej stan, konto uruchomieniowe, zależności oraz ostatnie wpisy w dzienniku błędów. Jeżeli usługa działa, należy odczytać stan konkretnej bazy w sys.databases i ustalić, czy pliki wskazane przez sys.master_files istnieją w oczekiwanych lokalizacjach. Następnie sprawdza się wolne miejsce, dostęp do woluminu, uprawnienia konta usługi oraz błędy sprzętowe i systemowe. Dopiero po zabezpieczeniu istniejących plików i ustaleniu możliwości odtworzenia kopii zapasowej można planować działania naprawcze.

Nie powinno się usuwać pliku dziennika, odłączać bazy, tworzyć pustego pliku o tej samej nazwie ani wymuszać zmiany stanu bez rozpoznania zależności między plikami danych i dziennika. W przypadku bazy działającej w środowisku produkcyjnym istotne jest zachowanie oryginalnych plików, zapisanie pełnych komunikatów oraz ustalenie ostatniej poprawnej kopii zapasowej. Jeżeli przyczyną jest uszkodzenie nośnika, sama operacja w SQL Server nie naprawi warstwy sprzętowej. Jeżeli natomiast problem wynika z błędnej ścieżki lub uprawnień, właściwe przywrócenie dostępu może pozwolić silnikowi na ponowne otwarcie bazy bez ingerencji w jej zawartość.