Błąd inicjalizacji instancji

Błąd inicjalizacji instancji sygnalizuje niepowodzenie procesu uruchamiania danej instancji serwera SQL.

Na czym polega błąd inicjalizacji instancji SQL Server

Błąd inicjalizacji instancji oznacza, że usługa konkretnej instancji Microsoft SQL Server nie zdołała przejść etapu uruchamiania. Instancja to odrębny zestaw procesów, konfiguracji, baz systemowych i parametrów nasłuchu działający w ramach silnika SQL Server. W instalacji domyślnej nosi nazwę MSSQLSERVER, natomiast instancja nazwana otrzymuje własny identyfikator, na przykład SQL2019. Sam komunikat o nieudanej inicjalizacji nie wskazuje jeszcze przyczyny. Informacja diagnostyczna znajduje się zwykle w dzienniku błędów SQL Server, dzienniku systemowym Windows oraz w szczegółach usługi.

Podczas uruchamiania silnik musi między innymi odczytać konfigurację, otworzyć bazy systemowe, uzyskać dostęp do plików danych i dzienników transakcji, zainicjować pamięć oraz uruchomić wymagane punkty komunikacyjne. Jeżeli którykolwiek z tych etapów zakończy się niepowodzeniem, usługa może natychmiast się zatrzymać. W efekcie aplikacje korzystające z tej instancji otrzymują błędy połączenia, a narzędzia administracyjne, takie jak SQL Server Management Studio, nie mogą nawiązać sesji z silnikiem.

Najczęstsze przyczyny zatrzymania usługi silnika

Jedną z typowych przyczyn jest brak dostępu do plików baz systemowych. SQL Server podczas startu korzysta przede wszystkim z baz master, model i msdb. Jeżeli plik danych lub dziennika został przeniesiony, usunięty, uszkodzony albo znajduje się na niedostępnym woluminie, instancja może nie wystartować. Problem występuje również wtedy, gdy konto usługi SQL Server nie ma praw do katalogu zawierającego pliki. Uprawnienie administratora użytkownika zalogowanego do Windows nie zastępuje uprawnień konta, pod którym działa usługa.

Inicjalizację może przerwać brak wolnego miejsca na dysku, ograniczenie przydziału pamięci, uszkodzenie systemu plików lub błąd urządzenia magazynującego. Znaczenie ma także konfiguracja parametrów startowych. Nieprawidłowa ścieżka podana przy parametrze -d wskazuje plik danych bazy master, parametr -l określa lokalizację jej dziennika, a -e wskazuje plik dziennika błędów SQL Server. Błędna wartość któregoś z tych parametrów może uniemożliwić uruchomienie procesu jeszcze przed dostępem do zwykłych baz użytkownika.

Do problemu może dojść również po zmianie konta usługi, aktualizacji systemu, odtworzeniu dysku z kopii lub przywróceniu konfiguracji na innym komputerze. W instancji nazwanej należy dodatkowo sprawdzić, czy uruchomiona jest właściwa usługa, na przykład SQL Server (SQL2019), a nie inna instancja z podobną nazwą. Błąd związany z portem sieciowym zwykle nie blokuje samego startu silnika, lecz może powodować brak połączenia zdalnego po prawidłowym uruchomieniu usługi. Rozróżnienie tych sytuacji ogranicza ryzyko naprawiania niewłaściwego elementu.

Odczyt dzienników i kontrola konfiguracji

Pierwszym źródłem informacji jest plik ERRORLOG instancji. Jego dokładna lokalizacja zależy od wersji, nazwy instancji i katalogu instalacyjnego, dlatego nie należy zakładać jednej ścieżki dla wszystkich komputerów. Lokalizację można sprawdzić w konfiguracji usługi SQL Server albo w SQL Server Configuration Manager. Jeżeli silnik nie uruchamia się wystarczająco długo, aby odczytać log przez zapytanie SQL, plik można otworzyć bezpośrednio po zatrzymaniu prób startu. W dzienniku należy szukać wpisów dotyczących otwarcia plików, błędów systemu Windows, odmowy dostępu, niewystarczającej ilości miejsca oraz nieudanych operacji odzyskiwania bazy master.

W Podglądzie zdarzeń Windows warto sprawdzić gałęzie Windows Logs oraz Application, a także zdarzenia związane z Service Control Manager. Kod błędu systemu plików, taki jak odmowa dostępu albo brak wskazanej ścieżki, trzeba interpretować razem z kontem usługi i rzeczywistą strukturą katalogów. W SQL Server Configuration Manager można zweryfikować konto usługi, parametry uruchomieniowe oraz ustawienia protokołów. Jeżeli problem dotyczy komunikacji, należy sprawdzić konfigurację TCP/IP, port instancji i zaporę, pamiętając, że te elementy nie naprawią uszkodzonego pliku bazy systemowej.

Przydatne jest porównanie bieżącej konfiguracji z ostatnim stanem, w którym instancja działała poprawnie. Należy ustalić, czy zmieniła się litera dysku, punkt montowania, nazwa katalogu, konto usługi lub polityka dostępu. Nie powinno się kasować plików .mdf i .ldf ani tworzyć nowych baz systemowych bez potwierdzenia przyczyny i posiadania aktualnej kopii zapasowej. W przypadku podejrzenia uszkodzenia magazynu najpierw zabezpiecza się kopię plików i sprawdza stan dysku, ponieważ wielokrotne próby uruchamiania mogą utrudnić późniejszą analizę.

Bezpieczne przywracanie działania instancji

Naprawa powinna wynikać z konkretnego wpisu w dzienniku, a nie z samego ogólnego komunikatu. Przy braku dostępu koryguje się uprawnienia katalogów dla właściwego konta usługi. Przy nieprawidłowej ścieżce przywraca się poprawne parametry startowe lub odtwarza pliki w lokalizacji zgodnej z konfiguracją. Gdy przyczyną jest zapełniony wolumin, trzeba zwolnić miejsce lub powiększyć magazyn przed kolejną próbą startu. Po każdej zmianie sprawdza się stan usługi oraz ponownie analizuje ERRORLOG, aby potwierdzić, że zniknął pierwotny błąd, a nie tylko zmieniła się kolejność komunikatów.

Jeśli uszkodzona jest baza master, standardowe uruchomienie może być niemożliwe i konieczne może okazać się odtworzenie jej z poprawnej kopii zapasowej albo użycie procedury naprawczej właściwej dla zainstalowanej wersji SQL Server. Takie działania wymagają zgodności wersji, znajomości parametrów instancji oraz przygotowania planu odtworzenia baz użytkownika i konfiguracji logowania. Po uruchomieniu należy zweryfikować dostępność baz, stan dzienników transakcji, zadania SQL Server Agent oraz połączenia aplikacji. Sama zmiana statusu usługi na „Uruchomiono” nie jest wystarczającym potwierdzeniem poprawnego działania całego środowiska.

W diagnostyce serwerowej ważne jest zachowanie kolejności: identyfikacja instancji, odczyt logów, sprawdzenie magazynu i uprawnień, kontrolowana korekta konfiguracji, a następnie test lokalnego i zdalnego połączenia. Dalsze kroki zależą od kodu błędu oraz wersji SQL Server. Dokumentacja powinna zawierać nazwę instancji, konto usługi, lokalizacje plików baz systemowych, wykonane zmiany i dokładny wynik ponownego uruchomienia. Taki zapis ułatwia odtworzenie sprawnej konfiguracji oraz odróżnienie awarii silnika od problemu sieciowego, systemowego lub sprzętowego.