Niedostępność instancji

Niedostępność instancji oznacza, że usługa SQL Server nie odpowiada na połączenia, choć serwer może działać.

Co oznacza niedostępność instancji SQL Server

Niedostępność instancji SQL Server oznacza, że klient nie może ustanowić połączenia z konkretną instancją silnika bazy danych. Nie musi to oznaczać wyłączenia całego serwera Windows. System operacyjny może odpowiadać na żądania, działać zdalny pulpit, udostępnienia plików albo inne usługi, podczas gdy usługa SQL Server nie działa, nie nasłuchuje na oczekiwanym porcie lub odrzuca połączenia. Istotne jest rozróżnienie między instancją domyślną a nazwanym wystąpieniem. Instancja domyślna jest zwykle adresowana nazwą serwera lub adresem IP, natomiast nazwana instancja ma postać na przykład NAZWA_SERWERA\PRODUKCJA.

Problem może pojawić się na kilku etapach. Klient może nie odnaleźć adresu serwera, nie ustalić portu przypisanego do nazwanej instancji, nie nawiązać połączenia TCP albo połączyć się z silnikiem, lecz otrzymać odmowę uwierzytelnienia. W pierwszych trzech przypadkach chodzi o dostępność instancji i komunikację sieciową, a nie o uprawnienia do konkretnej bazy. Komunikaty klientów, takie jak „server not found”, „error 26” lub „error 40”, wskazują na niepowodzenie lokalizacji albo otwarcia połączenia, ale same w sobie nie identyfikują jeszcze przyczyny źródłowej.

Usługa silnika, port TCP i SQL Server Browser

Podstawowym elementem jest usługa właściwego silnika, nosząca dla instancji domyślnej nazwę MSSQLSERVER, a dla nazwanej instancji nazwę w rodzaju MSSQL$PRODUKCJA. Jeżeli usługa jest zatrzymana, instancja nie przyjmie połączeń. Jeżeli uruchamia się i natychmiast kończy pracę, przyczyną może być między innymi nieprawidłowa konfiguracja, brak dostępu do plików baz danych, zajęty port albo błąd odnotowany w dzienniku SQL Server. Stan usługi należy sprawdzać w usługach systemu Windows lub w SQL Server Configuration Manager, ponieważ ten ostatni pokazuje również ustawienia sieciowe SQL Server.

Połączenia do silnika odbywają się przez protokół TCP/IP, gdy klient korzysta z komunikacji sieciowej. Numer portu nie jest cechą stałą każdej instancji. Instancja domyślna często używa portu TCP 1433, ale administrator może ustawić inny port. Nazwane instancje mogą korzystać z portów dynamicznych. W takim układzie usługa SQL Server Browser, działająca jako SQLBrowser, pomaga klientowi ustalić port nazwanej instancji. Browser wykorzystuje UDP na porcie 1434. Zablokowanie UDP 1434 może uniemożliwić odnalezienie portu nazwanej instancji, nawet gdy sam silnik działa i nasłuchuje na TCP. Alternatywą jest podanie klientowi konkretnego numeru portu, na przykład w formie NAZWA_SERWERA,51433, oraz dopuszczenie tego portu w zaporze.

Rozdzielenie problemu między sieć a konfigurację SQL Server

Diagnostykę warto prowadzić od ustalenia, czy problem dotyczy jednej stacji, czy wszystkich klientów. Jeżeli tylko jeden komputer nie może się połączyć, należy sprawdzić nazwę serwera, lokalny DNS, profil sieci, zaporę na tej stacji oraz poprawność wpisanej nazwy instancji. Jeżeli połączenia nie działają z wielu komputerów, większe znaczenie ma stan usługi SQL Server, konfiguracja nasłuchiwania, reguły zapory na serwerze i dostępność właściwego adresu sieciowego. Próba połączenia z lokalnego serwera przez localhost lub lokalny adres może pomóc oddzielić problem silnika od problemu trasy sieciowej, ale nie zastępuje sprawdzenia konfiguracji używanej przez aplikację.

Dla instancji, która powinna nasłuchiwać na określonym porcie, można zweryfikować obecność nasłuchu TCP narzędziami systemowymi, na przykład poleceniem Test-NetConnection NAZWA_SERWERA -Port 1433 w PowerShellu. Wynik dodatni potwierdza możliwość zestawienia połączenia TCP z tym portem, lecz nie potwierdza poprawnego uwierzytelnienia ani dostępności konkretnej bazy. Wynik ujemny kieruje uwagę na port, adres, trasę lub zaporę. W SQL Server Configuration Manager należy sprawdzić, czy protokół TCP/IP jest włączony dla właściwej instancji, jaki port znajduje się w sekcji adresów IP oraz czy po zmianie ustawień usługa została ponownie uruchomiona. Szczegółowych przyczyn należy szukać w pliku ERRORLOG SQL Server, Podglądzie zdarzeń Windows i logach aplikacji klienckiej.

Przywracanie połączeń i kontrola po zmianach

Naprawa zależy od potwierdzonej przyczyny. Gdy usługa silnika jest zatrzymana, należy ustalić, dlaczego nie wystartowała, zamiast wielokrotnie uruchamiać ją bez analizy logów. Gdy problemem jest zapora, reguła powinna zezwalać na właściwy port TCP używany przez konkretną instancję. Przy nazwanej instancji trzeba dodatkowo zapewnić działanie SQL Server Browser i komunikację UDP 1434 albo skonfigurować stały port oraz używać go jawnie w parametrach połączenia. Po zmianie portu, włączeniu TCP/IP lub zmianie trybu nasłuchiwania konieczne jest ponowne uruchomienie odpowiedniej usługi, a następnie sprawdzenie połączenia z rzeczywistego komputera klienta.

Kontrola nie powinna kończyć się na samym otwarciu portu. Należy wykonać próbę połączenia przy użyciu tej samej nazwy serwera, instancji i parametrów, których używa aplikacja, a następnie potwierdzić dostęp do wymaganej bazy oraz wykonanie prostego zapytania. Warto również sprawdzić, czy aplikacja nie korzysta ze starego numeru portu, nie wskazuje nieistniejącej instancji albo nie przełącza się na błędny adres po nieudanym połączeniu. W środowisku serwerowym każdą zmianę trzeba odnotować w konfiguracji i monitoringu, aby kolejne zatrzymanie usługi, zmianę portu lub blokadę zapory można było odróżnić od awarii samej bazy danych.