Błąd SQL Server

Błąd SQL Server to ogólne określenie dowolnej usterki związanej z działaniem tego systemu zarządzania bazami danych.

Jak rozumieć błąd SQL Server

Błąd SQL Server jest komunikatem informującym o nieprawidłowości w działaniu aparatu bazodanowego Microsoft SQL Server albo aplikacji, która korzysta z tego silnika. Przyczyną może być odrzucone uwierzytelnienie, brak uprawnień, niedostępna baza, konflikt transakcji, naruszenie ograniczenia integralności, brak miejsca na dysku lub problem z odczytem pliku bazy danych. Samo określenie „błąd SQL Server” nie wskazuje jeszcze konkretnej przyczyny. Do rozpoznania potrzebny jest numer błędu, pełna treść komunikatu, czas wystąpienia i kontekst operacji.

SQL Server zapisuje część informacji diagnostycznych w dzienniku błędów instancji, którego główny plik jest często nazywany ERRORLOG. Komunikaty mogą być również rejestrowane w dzienniku aplikacji systemu Windows, dzienniku agenta SQL Server oraz sesjach Extended Events. Wbudowany katalog komunikatów można przeglądać między innymi przez widok sys.messages. Numer komunikatu i poziom ważności pomagają odróżnić błąd dotyczący pojedynczego zapytania od problemu wpływającego na całą instancję lub bazę.

Typowe kategorie komunikatów i ich przyczyny

Błąd 18456 oznacza nieudane logowanie do instancji SQL Server. Przyczyną może być niepoprawne hasło, wyłączony login, niedozwolony typ uwierzytelniania albo brak dostępu do wskazanej bazy. Błąd 4060 wskazuje, że logowanie do określonej bazy nie powiodło się. Błąd 229 jest związany z brakiem uprawnień do wykonania konkretnej operacji, natomiast błąd 2627 zwykle oznacza naruszenie klucza głównego lub ograniczenia UNIQUE. Błąd 547 informuje o naruszeniu ograniczenia klucza obcego albo innego ograniczenia kontrolnego.

Problemy mogą dotyczyć również zasobów. Błąd 9002 oznacza zapełnienie dziennika transakcji, a błąd 1105 informuje o braku miejsca przy próbie przydzielenia obszaru w bazie. Błąd 1205 opisuje zakleszczenie, czyli sytuację, w której transakcje wzajemnie blokują zasoby i SQL Server wybiera jedną z nich jako ofiarę do wycofania. Komunikaty 823 i 824 dotyczą błędów wejścia-wyjścia lub niespójności odczytu stron danych. Błąd 825 sygnalizuje powtarzającą się próbę odczytu strony i może wskazywać na problemy z podsystemem pamięci masowej.

Ścieżka diagnostyczna od komunikatu do źródła problemu

Diagnostykę należy rozpocząć od zebrania pełnego komunikatu, a nie od samego zdania wyświetlonego w interfejsie programu. Istotne są numer błędu, stan komunikatu, nazwa bazy, nazwa obiektu, login, polecenie wykonywane w chwili awarii oraz znacznik czasu. Następnie porównuje się ten czas z wpisami w ERRORLOG, dziennikach systemowych i logach aplikacji. Pozwala to ustalić, czy problem pojawił się podczas uruchamiania instancji, połączenia, wykonywania zapytania, zapisu danych czy operacji kopii zapasowej.

Przy podejrzeniu blokowania analizuje się aktywne sesje, oczekiwania i łańcuchy blokad. Przy zakleszczeniach pomocne jest zdarzenie deadlock graph rejestrowane przez Extended Events. W przypadku podejrzenia uszkodzenia bazy stosuje się DBCC CHECKDB, które sprawdza logiczną i fizyczną spójność struktur. Wyniku tego polecenia nie należy utożsamiać z automatyczną naprawą. Opcje naprawcze DBCC mogą prowadzić do utraty danych, dlatego najpierw weryfikuje się kopie zapasowe, stan plików oraz możliwość odtworzenia bazy w bezpiecznym środowisku.

Nie każdy błąd SQL Server oznacza uszkodzenie samego silnika. Często źródłem jest błędny ciąg połączenia, wygasłe poświadczenie, niezgodny typ danych, nieprawidłowa kolejność operacji albo aplikacja wysyłająca zapytania bez obsługi transakcji i błędów. Dlatego ocena powinna obejmować zarówno konfigurację instancji i bazy, jak i kod klienta, sterownik oraz warunki systemowe, takie jak wolne miejsce, dostępność pamięci i stan dysków.

Bezpieczne postępowanie po wystąpieniu błędu

Po pojawieniu się komunikatu nie należy usuwać dzienników ani wielokrotnie ponawiać operacji bez ustalenia przyczyny. Powtarzane zapisy mogą pogłębić problem z miejscem w dzienniku transakcji, a niekontrolowane restarty mogą utrudnić odtworzenie kolejności zdarzeń. Najpierw zabezpiecza się treść komunikatu i aktualny stan systemu, a następnie sprawdza, czy błąd jest powtarzalny, dotyczy jednej bazy, jednego użytkownika, konkretnego zapytania czy całej instancji.

Naprawa zależy od kategorii błędu. Przy problemach z logowaniem sprawdza się tryb uwierzytelniania, status loginu i mapowanie użytkownika do bazy. Przy braku uprawnień analizuje się role oraz uprawnienia do konkretnego obiektu, bez przyznawania szerszego dostępu niż wymagany. Przy zapełnieniu dziennika ustala się przyczynę wzrostu, model odzyskiwania i poprawność strategii kopii zapasowych dziennika. Przy błędach 823, 824 lub 825 konieczna jest kontrola warstwy pamięci masowej oraz spójności bazy, ponieważ samo ponowienie zapytania nie usuwa potencjalnej przyczyny.

Diagnostyka i naprawa komputera, na którym działa aplikacja korzystająca z SQL Server, obejmuje także sprawdzenie systemu Windows, usług, sterowników, połączenia sieciowego oraz lokalnych logów programu. W przypadku środowiska serwerowego zakres czynności powinien zostać ustalony na podstawie uprawnień administratora, dostępnych kopii zapasowych i procedur utrzymaniowych. Najważniejsze jest zachowanie danych źródłowych, udokumentowanie wykonanych zmian i potwierdzenie po naprawie, że aplikacja może poprawnie nawiązać połączenie oraz wykonać wymagane operacje.