Error 17058 – błąd uruchomienia SQL Server

Error 17058 sygnalizuje niepowodzenie uruchomienia usługi SQL Server, zwykle wymagające analizy dziennika błędów.

Co oznacza komunikat SQL Server Error 17058

Błąd 17058 pojawia się podczas uruchamiania usługi aparatu Microsoft SQL Server. Nie oznacza pojedynczej, zawsze takiej samej usterki bazy danych, lecz informuje, że proces serwera nie zdołał prawidłowo zainicjować dziennika błędów lub innego elementu wymaganego na początku pracy. W praktyce komunikat jest często widoczny w Podglądzie zdarzeń systemu Windows, w dzienniku aplikacji albo w historii uruchamiania usługi SQL Server.

Najważniejszym źródłem informacji jest treść wpisu poprzedzająca lub następująca po numerze 17058. W wielu przypadkach znajduje się tam komunikat initerrlog oraz informacja o niemożności otwarcia pliku dziennika błędów. Może pojawić się także kod błędu systemu operacyjnego, na przykład wskazujący na nieistniejącą ścieżkę albo brak dostępu. Sam numer 17058 nie wystarcza więc do wskazania przyczyny bez analizy pełnego wpisu, konfiguracji instancji i stanu systemu Windows.

Ścieżki startowe i plik ERRORLOG

Podczas startu SQL Server korzysta z parametrów uruchomieniowych określających między innymi lokalizację głównego pliku danych systemowej bazy master, pliku dziennika tej bazy oraz pliku dziennika błędów. W konfiguracji instancji są one zwykle oznaczone parametrami -d, -l i -e. Parametr -e wskazuje katalog lub plik używany dla dziennika błędów SQL Server. Jeżeli wskazana lokalizacja nie istnieje, została zmieniona, znajduje się na niedostępnym dysku albo zawiera nieprawidłową wartość, inicjalizacja serwera może zakończyć się błędem 17058.

Analiza powinna obejmować także plik ERRORLOG oraz jego kolejne kopie, o ile zostały utworzone. Wpisy w tym pliku pokazują kolejność czynności wykonywanych przez silnik i mogą ujawnić, czy problem wystąpił przed otwarciem baz systemowych, przy odczycie konfiguracji, podczas tworzenia gniazda sieciowego czy przy uzyskiwaniu dostępu do plików. Nie należy usuwać dziennika przed jego skopiowaniem, ponieważ może zawierać jedyny dokładny opis awarii. Warto również sprawdzić, czy wolumin ma dostępne miejsce i czy ścieżka nie prowadzi do odłączonego dysku lub udziału sieciowego.

Weryfikację parametrów najlepiej przeprowadzić w SQL Server Configuration Manager, ponieważ narzędzie uwzględnia sposób zainstalowania instancji i pozwala odróżnić usługę domyślną od nazwanej. Zmiana parametru startowego bez zachowania istniejących wartości może spowodować dodatkowe problemy, zwłaszcza gdy usunięte zostaną poprawne odwołania do plików master. Każdą zmianę należy dokumentować i wykonywać dopiero po zapisaniu aktualnej konfiguracji.

Uprawnienia konta usługi i zależności systemowe

SQL Server uruchamia się przy użyciu określonego konta usługi. Konto to musi mieć możliwość odczytu i zapisu w katalogach potrzebnych do uruchomienia instancji, w tym w lokalizacji dziennika błędów oraz w katalogach zawierających pliki baz systemowych. Uprawnienia konta usługi mogą zostać utracone po ręcznej zmianie zabezpieczeń NTFS, przeniesieniu katalogu, odtworzeniu danych z kopii albo zmianie konta przypisanego do usługi. Sam fakt, że administrator systemu może otworzyć plik, nie dowodzi, że dostęp ma również konto używane przez SQL Server.

Podczas diagnostyki należy porównać nazwę konta skonfigurowanego dla usługi z uprawnieniami do konkretnych folderów i plików. Trzeba sprawdzić również, czy pliki nie są zablokowane przez oprogramowanie zabezpieczające, szyfrowanie woluminu, filtr systemu plików lub proces wykonujący kopię zapasową. Istotny jest także stan usług zależnych i samego systemu Windows: uszkodzenie profilu usługi, błędy dysku, niedostępność woluminu po starcie systemu albo niepełna aktualizacja mogą wpływać na uruchomienie SQL Server.

Jeśli usługa kończy pracę natychmiast po wydaniu polecenia uruchomienia, ponawianie startu bez zebrania logów zwykle nie dostarcza nowych informacji. Należy zestawić wpis z Podglądu zdarzeń, logu SQL Server i dziennika systemowego, a następnie sprawdzić czas wystąpienia zdarzeń. Taka korelacja pomaga odróżnić błąd ścieżki lub uprawnień od uszkodzenia pliku, problemu z woluminem albo niezgodności parametrów po zmianie konfiguracji.

Bezpieczna kolejność postępowania przy awarii startu

Najpierw należy ustalić nazwę instancji, dokładny komunikat i konto usługi, a następnie zabezpieczyć istniejące logi oraz aktualną konfigurację parametrów startowych. Kolejny etap obejmuje sprawdzenie istnienia wskazanych ścieżek, dostępności dysku, wolnego miejsca i praw NTFS. Jeżeli przyczyną jest błędna lokalizacja dziennika, korekta powinna przywrócić prawidłową ścieżkę dla tej konkretnej instalacji, bez przenoszenia plików na nowy wolumin bez wcześniejszego sprawdzenia uprawnień i zależności.

Nie należy od razu usuwać baz systemowych, reinstalować SQL Server ani uruchamiać operacji naprawczych na plikach danych. Takie działania mogą utrudnić odtworzenie przyczyny i zwiększyć ryzyko utraty konfiguracji. Jeżeli diagnostyka wskazuje na uszkodzenie pliku master lub problem z nośnikiem, potrzebna jest osobna ocena stanu plików, kopii zapasowych i integralności systemu plików. Po usunięciu przyczyny trzeba potwierdzić start usługi, utworzenie aktualnego pliku ERRORLOG, dostęp do baz systemowych oraz poprawne działanie klientów korzystających z instancji.

Diagnostyka błędu 17058 powinna opierać się na logach i konfiguracji konkretnej instancji, a nie na samym numerze komunikatu. W przypadku pracy na komputerze stacjonarnym lub laptopie, na którym lokalnie zainstalowano SQL Server, przydatne jest zebranie pełnych wpisów przed rozpoczęciem naprawy oraz zachowanie kopii plików konfiguracyjnych i danych. Pozwala to ocenić, czy problem dotyczy wyłącznie uruchomienia usługi, czy również stanu baz i nośnika przechowującego pliki.