Diagnostyka błędów SSMS

Diagnostyka błędów SSMS to proces analizy przyczyn nieprawidłowości w działaniu narzędzia SQL Server Management Studio.

Zakres diagnostyki błędów SSMS

Diagnostyka błędów SQL Server Management Studio (SSMS) zaczyna się od rozdzielenia problemu narzędzia klienckiego od problemu aparatu bazodanowego SQL Server. SSMS jest aplikacją służącą między innymi do nawiązywania połączeń, wykonywania zapytań, zarządzania obiektami bazy oraz odczytywania komunikatów zwracanych przez serwer. Sam fakt, że SSMS wyświetla błąd, nie oznacza więc, że przyczyna znajduje się w jego plikach. Źródłem problemu może być nieuruchomiona usługa SQL Server, nieprawidłowa nazwa instancji, brak uprawnień, blokada sieciowa, niedostępny protokół komunikacyjny albo błąd konkretnego zapytania.

W pierwszym etapie należy ustalić, kiedy pojawia się nieprawidłowość: podczas uruchamiania programu, wyboru serwera, uwierzytelniania, otwierania bazy, wykonywania zapytania czy korzystania z określonego okna administracyjnego. Znaczenie ma również treść komunikatu, jego numer oraz etap operacji, na którym występuje. Błąd logowania do serwera wymaga innego postępowania niż komunikat o odmowie dostępu do obiektu, przekroczeniu limitu czasu zapytania lub problemie z ładowaniem rozszerzenia SSMS.

Połączenie z instancją SQL Server

Przy błędach połączenia sprawdza się nazwę serwera i instancji wpisaną w oknie „Connect to Server”. Instancja domyślna jest zwykle wskazywana samą nazwą hosta, natomiast instancja nazwana ma postać nazwa_hosta\nazwa_instancji. W środowisku lokalnym można spotkać także oznaczenie localhost, kropkę lub nazwę komputera, ale każda z tych wartości odnosi się do konkretnego miejsca uruchomienia aparatu SQL Server. Wpisanie poprawnej nazwy komputera nie gwarantuje połączenia, jeśli usługa właściwej instancji jest zatrzymana.

Należy odróżnić uwierzytelnianie Windows od uwierzytelniania SQL Server. Pierwszy mechanizm wykorzystuje konto systemu Windows, a drugi wymaga loginu skonfigurowanego w SQL Server i właściwego hasła. Konto może poprawnie logować się do systemu operacyjnego, ale nie mieć prawa połączenia z daną instancją lub dostępu do konkretnej bazy. Przy analizie komunikatu trzeba też sprawdzić, czy problem dotyczy rozpoznania serwera, odrzucenia poświadczeń, braku uprawnienia do bazy, czy zerwania połączenia już po udanym logowaniu.

Jeżeli połączenie przebiega przez sieć, diagnostyka obejmuje dostępność hosta, port używany przez SQL Server, reguły zapory oraz konfigurację protokołów sieciowych obsługiwanych przez instancję. Dla instancji nazwanych dodatkowym elementem może być SQL Server Browser, który pomaga klientowi ustalić port instancji. Komunikat o przekroczeniu limitu czasu nie jest dowodem błędnego hasła; może oznaczać, że klient nie otrzymał odpowiedzi w wymaganym czasie albo nie może dotrzeć do właściwego endpointu.

Interpretacja komunikatów, logów i zapytań

SSMS prezentuje komunikaty w różnych miejscach. Błąd wykonania zapytania jest zwykle widoczny w panelu „Messages”, a wynik zapytania pojawia się osobno w panelu „Results”. Przydatne są numer błędu, poziom ważności, stan, procedura i numer wiersza, jeżeli SQL Server zwrócił te informacje. Numer wiersza wskazuje pozycję w aktualnie wykonywanym tekście lub partii poleceń, dlatego przy analizie trzeba uwzględnić komentarze, poprzednie instrukcje oraz sposób podziału skryptu na partie za pomocą polecenia GO.

Komunikaty składniowe, takie jak nieprawidłowa nazwa obiektu lub kolumny, wymagają sprawdzenia kontekstu bazy, schematu i aktualnie używanej bazy danych. Ta sama nazwa tabeli może działać w jednej bazie, a nie działać w innej. Warto zweryfikować, czy obiekt istnieje, czy użytkownik ma prawo go odczytać oraz czy zapytanie nie odwołuje się do obiektu usuniętego albo przemianowanego. Błędy blokad i przekroczeń czasu wykonania analizuje się inaczej: wtedy znaczenie mają aktywne sesje, transakcje, oczekiwania oraz obciążenie aparatu SQL Server.

W przypadku problemów z samym SSMS sprawdza się dzienniki aplikacji, konfigurację profilu użytkownika, dodatki, rozszerzenia oraz uszkodzone ustawienia interfejsu. Nie należy jednak usuwać plików konfiguracyjnych bez ustalenia ich roli, ponieważ można utracić zapisane preferencje lub utrudnić odtworzenie przyczyny. Jeżeli błąd występuje tylko przy jednym zapytaniu, należy porównać jego działanie z prostym zapytaniem testowym, na przykład odczytem bieżącej nazwy bazy. Pozwala to ustalić, czy problem dotyczy komunikacji z serwerem, uprawnień, konkretnego obiektu, czy logiki instrukcji SQL.

Uprawnienia, szyfrowanie i dalsze kroki

Diagnostyka może obejmować także negocjowanie szyfrowanego połączenia. W takim przypadku znaczenie ma zgodność ustawień klienta i serwera, zaufanie do certyfikatu, nazwa hosta użyta podczas połączenia oraz obsługiwane ustawienia TLS. Ostrzeżenie dotyczące certyfikatu nie powinno być traktowane jako zwykły błąd hasła. Należy ustalić, czy certyfikat jest ważny, czy odpowiada nazwie serwera i czy klient może zweryfikować łańcuch zaufania. Zmiana ustawień bezpieczeństwa bez rozpoznania przyczyny może jedynie ukryć problem.

Przy błędach uprawnień trzeba rozpatrywać kilka poziomów dostępu: możliwość zalogowania się do instancji, dostęp do bazy, prawa do schematu oraz uprawnienia do tabel, widoków, procedur lub innych obiektów. Użytkownik może widzieć bazę w Object Explorer, ale nie mieć prawa wykonania określonej operacji. Odwrotna sytuacja również jest możliwa, gdy zapytanie działa, lecz część obiektów nie jest widoczna w interfejsie z powodu ograniczeń metadanych.

Końcowy etap powinien zawierać odtworzenie błędu w kontrolowanych warunkach, zapis dokładnego komunikatu, godzinę wystąpienia, nazwę instancji, sposób uwierzytelniania oraz zakres operacji wykonanej w SSMS. Dopiero takie dane pozwalają porównać zachowanie aplikacji z dziennikiem SQL Server i ustalić, czy potrzebna jest korekta konfiguracji klienta, uprawnień, połączenia albo samego zapytania. W zastosowaniach związanych z administracją SQL Server naprawa powinna być prowadzona ostrożnie, ponieważ przypadkowe zmiany konfiguracji lub uprawnień mogą wpłynąć na działanie baz i aplikacji korzystających z serwera.