823 – Błąd odczytu/zapisu dysku

Błąd 823 sygnalizuje problem sprzętowy lub systemowy podczas odczytu lub zapisu na dysku, wykryty przez serwer SQL.

Co oznacza komunikat SQL Server 823

Błąd 823 w Microsoft SQL Server oznacza, że podczas operacji wejścia-wyjścia system operacyjny zwrócił do silnika bazy danych błąd dotyczący pliku używanego przez bazę. Operacją może być odczyt albo zapis. SQL Server zapisuje wtedy w komunikacie między innymi rodzaj wykonanej operacji, ścieżkę pliku, położenie danych w pliku oraz kod błędu systemu Windows. Nie jest to zwykły komunikat o niepoprawnym zapytaniu SQL. Wskazuje na problem występujący niżej, na poziomie systemu operacyjnego, sterownika, kontrolera, nośnika danych albo infrastruktury przechowywania.

Komunikat 823 ma zwykle wysoką ważność, ponieważ błędna operacja wejścia-wyjścia może uniemożliwić odczyt strony danych, zapis zmodyfikowanej strony lub wykonanie operacji wymaganej przez odzyskiwanie bazy. Sam numer 823 nie określa jeszcze, czy uszkodzeniu uległ konkretny plik bazy, cały dysk, połączenie z macierzą, sterownik czy element sprzętowy. Do interpretacji potrzebny jest pełny tekst komunikatu, zwłaszcza kod błędu systemu operacyjnego i informacja, którego pliku dotyczy zdarzenie.

Różnica między błędem fizycznego I/O a niespójnością strony

W SQL Server błąd 823 dotyczy przede wszystkim nieudanego żądania wejścia-wyjścia zgłoszonego przez system operacyjny. Jest to inna sytuacja niż błąd 824, który sygnalizuje logiczny problem z zawartością strony odczytanej pozornie poprawnie, na przykład nieprawidłową sumę kontrolną lub niespójność struktury strony. Błąd 825 ma jeszcze inny charakter: informuje o ponowieniu operacji odczytu, które zakończyło się powodzeniem, ale może wskazywać na problemy z podsystemem dyskowym.

Rozróżnienie tych komunikatów ma znaczenie diagnostyczne. Przy 823 należy najpierw ustalić, jaki kod systemu Windows został zwrócony i czy w tym samym czasie wystąpiły zdarzenia dotyczące dysku, kontrolera, systemu plików lub połączenia z pamięcią masową. Przy 824 konieczne jest dodatkowo sprawdzenie integralności struktur bazy, ponieważ system mógł zwrócić dane, których zawartość nie spełnia wymagań SQL Server. Nie należy zamieniać numerów tych błędów ani traktować ich jako równoważnych nazw uszkodzenia dysku.

Jak ustala się źródło problemu w środowisku SQL Server

Analizę rozpoczyna się od zebrania pełnego wpisu z dziennika błędów SQL Server oraz odpowiadających mu zdarzeń w Podglądzie zdarzeń systemu Windows. Trzeba porównać czas wystąpienia błędu z informacjami o resetach urządzenia, błędach kontrolera, utracie ścieżki do dysku, błędach systemu plików i problemach sterownika. Istotna jest także identyfikacja pliku wskazanego w komunikacie: może to być plik danych z rozszerzeniem MDF lub NDF, plik dziennika transakcji LDF albo inny plik używany przez instancję.

Następnie sprawdza się stan nośnika i całej ścieżki I/O: dysku, kontrolera, przewodów lub połączeń, sterowników, oprogramowania obsługującego macierz oraz warstwy systemu plików. W środowisku wirtualnym analizuje się również warstwę przechowywania udostępniającą maszynie wirtualnej dysk, ale sam komunikat SQL Server nie pozwala przypisać winy konkretnej warstwie. Testy powinny być wykonywane zgodnie z dokumentacją producenta i z uwzględnieniem obciążenia działającej bazy. Bezpośrednie skanowanie lub naprawa nośnika podczas pracy może pogorszyć sytuację.

Po zabezpieczeniu kopii zapasowych można uruchomić kontrolę spójności bazy poleceniem DBCC CHECKDB. Wynik tego polecenia odpowiada na pytanie, czy wykryto niespójności struktur bazy, ale nie zastępuje diagnostyki podsystemu dyskowego i nie naprawia przyczyny błędu 823. Opcje naprawcze DBCC CHECKDB mogą prowadzić do utraty danych, dlatego nie powinny być używane automatycznie jako pierwsza reakcja. Jeżeli błąd dotyczy awarii urządzenia lub niedostępnego pliku, priorytetem jest przywrócenie sprawnego dostępu do pamięci masowej oraz odtworzenie bazy z prawidłowej kopii zapasowej.

Postępowanie po wystąpieniu błędu 823

Nie należy usuwać wpisu z dziennika ani wielokrotnie restartować instancji bez ustalenia przyczyny. Restart może chwilowo przerwać komunikaty, lecz nie usuwa uszkodzenia, niestabilnego połączenia ani problemu z zapisem. Należy zanotować czas zdarzenia, nazwę bazy, nazwę pliku, operację odczytu lub zapisu oraz systemowy kod błędu. Te dane pozwalają zestawić komunikat SQL Server ze stanem sprzętu i logami systemu.

Jeżeli baza pozostaje dostępna, należy zweryfikować możliwość wykonania kopii zapasowej i sprawdzić, czy nie występują kolejne błędy 823, 824 lub 825. W przypadku powtarzających się problemów trzeba ograniczyć obciążenie wadliwej ścieżki, skonsultować stan urządzenia z administratorem infrastruktury oraz przygotować plan odtworzenia. Gdy błąd pojawia się na komputerze używanym jako stacja robocza z lokalnym SQL Server, diagnostyka powinna objąć także stan dysku, temperatury, zasilanie, pamięć operacyjną i sterowniki kontrolera. Dopiero po usunięciu przyczyny sprzętowej lub systemowej można wiarygodnie ocenić, czy pozostały problemy w samej bazie.

W środowisku serwerowym naprawa wymaga rozdzielenia dwóch zagadnień: sprawności podsystemu wejścia-wyjścia oraz integralności danych SQL Server. Wymiana nośnika bez sprawdzenia kopii zapasowych może utrudnić odzyskanie danych, a samo odtworzenie bazy nie rozwiąże problemu, jeśli wadliwa infrastruktura nadal obsługuje pliki. Błąd 823 powinien być więc traktowany jako sygnał wymagający analizy całego łańcucha zapisu i odczytu, a nie jako pojedyncza usterka aplikacji.