Wsparcie techniczne SQL Server

Wsparcie techniczne SQL Server obejmuje pomoc producenta lub partnera w diagnozowaniu problemów z instancją.

Zakres wsparcia technicznego dla instancji SQL Server

Wsparcie techniczne SQL Server obejmuje analizę problemów związanych z działaniem instancji, baz danych, usług systemu Windows oraz aplikacji korzystających z połączeń TDS. Diagnoza zaczyna się od ustalenia, czy problem dotyczy uruchomienia usługi SQL Server, uwierzytelniania użytkownika, dostępności konkretnej bazy, wydajności zapytań, blokad, uszkodzenia stron danych, kopii zapasowych albo konfiguracji połączenia. Istotne jest rozdzielenie objawu od przyczyny: komunikat aplikacji może informować jedynie o przekroczeniu limitu czasu, podczas gdy rzeczywistym powodem jest blokada transakcji, brak miejsca na dysku lub oczekiwanie na operację wejścia-wyjścia.

W ramach wsparcia można sprawdzić nazwę instancji, stan usługi, port używany przez Database Engine, konfigurację protokołów w SQL Server Configuration Manager oraz sposób uwierzytelniania. SQL Server obsługuje uwierzytelnianie Windows i uwierzytelnianie SQL Server, jeśli tryb mieszany został włączony w konfiguracji instancji. Błąd logowania wymaga odróżnienia nieprawidłowego hasła, wyłączonego loginu, braku mapowania loginu na użytkownika bazy oraz braku uprawnień do wykonania konkretnej operacji.

Logi, komunikaty błędów i ślady aktywności

Podstawowym źródłem informacji o pracy Database Engine jest dziennik błędów SQL Server. Zawiera on między innymi informacje o uruchomieniu i zatrzymaniu instancji, błędach odczytu i zapisu, problemach z plikami baz danych, próbach logowania oraz zdarzeniach związanych z odzyskiwaniem bazy po restarcie. Dodatkowe dane mogą znajdować się w Podglądzie zdarzeń systemu Windows, szczególnie w dziennikach Application i System. Analiza powinna uwzględniać dokładny czas zdarzenia, identyfikator błędu, nazwę bazy oraz powtarzalność komunikatu.

W zapytaniach diagnostycznych przydatne są dynamiczne widoki zarządzania, między innymi sys.dm_exec_requests, sys.dm_exec_sessions, sys.dm_os_waiting_tasks i sys.dm_tran_locks. Pozwalają one ustalić, które żądania są aktywne, na co oczekują sesje oraz czy transakcje wzajemnie się blokują. Tekst wykonywanego zapytania można powiązać z uchwytem planu przez funkcje takie jak sys.dm_exec_sql_text. Przy interpretacji wyników trzeba pamiętać, że widoki DMV pokazują stan bieżący albo dane zależne od czasu działania instancji, więc pojedynczy odczyt nie zawsze opisuje problem, który już ustąpił.

Wydajność zapytań, blokady i integralność baz

Spadek wydajności SQL Server może wynikać z nieoptymalnego planu wykonania, nieaktualnych statystyk, brakujących indeksów, nadmiernej liczby operacji wejścia-wyjścia, blokad lub ograniczeń zasobów procesora i pamięci. Sam czas odpowiedzi aplikacji nie wskazuje jeszcze konkretnej przyczyny. Należy porównać czas trwania zapytania, typ oczekiwania, liczbę odczytanych stron, użyty plan wykonania oraz wpływ równoległych operacji wykonywanych przez inne sesje. W przypadku blokady ważne jest wskazanie sesji blokującej, a nie tylko sesji oczekującej.

Do kontroli logicznej i fizycznej spójności bazy służy polecenie DBCC CHECKDB. Raportuje ono problemy dotyczące między innymi alokacji stron, struktur tabel, indeksów i powiązań między obiektami. Uruchomienie tego polecenia może wymagać znacznych zasobów i powinno być zaplanowane z uwzględnieniem obciążenia instancji. Nie należy traktować automatycznego usuwania błędów jako pierwszego kroku; bezpieczniejszym punktem odniesienia jest kopia zapasowa oraz ustalenie, czy problem można naprawić przez odtworzenie danych z poprawnego backupu.

Procedura obsługi zgłoszenia i przywracania działania

Skuteczne wsparcie powinno rozpocząć się od zebrania informacji możliwych do zweryfikowania: wersji i edycji SQL Server, nazwy instancji, nazwy bazy, czasu wystąpienia problemu, treści komunikatu, sposobu łączenia aplikacji oraz ostatnich zmian w konfiguracji. Należy także sprawdzić stan plików danych i dziennika transakcji, dostępne miejsce na woluminach, wyniki ostatnich kopii zapasowych oraz ewentualne zadania SQL Server Agent. Jeżeli problem dotyczy tylko jednej aplikacji, warto porównać jej połączenie z niezależnym testem wykonanym w narzędziu przeznaczonym do pracy z SQL Server.

Przywracanie działania powinno być wykonywane w kolejności ograniczającej ryzyko utraty danych. Najpierw zabezpiecza się dostępne logi i informacje diagnostyczne, następnie potwierdza stan usługi, zasobów systemowych, bazy oraz kopii zapasowych. Restart instancji może usunąć chwilowy objaw, ale nie rozwiązuje blokady wynikającej z błędnej logiki aplikacji, przepełnionego dziennika transakcji ani uszkodzenia plików. Po wykonaniu zmiany trzeba sprawdzić ponowne logowania, działanie zapytań, status zadań oraz wpisy w dzienniku błędów.

W dokumentacji zgłoszenia warto zapisać przyczynę ustaloną na podstawie dowodów, wykonane polecenia, zmienione ustawienia i sposób potwierdzenia poprawy. Taki zapis ułatwia odróżnienie trwałego rozwiązania od tymczasowego obejścia i pozwala szybko porównać przyszłe incydenty z wcześniejszymi. W przypadku problemów z bazą produkcyjną każda operacja naprawcza powinna uwzględniać możliwość odtworzenia środowiska testowego oraz kontrolę poprawności backupów przed rozpoczęciem odtwarzania.