Error 823 – błąd I/O

Error 823 sygnalizuje problem sprzętowy lub systemowy podczas operacji wejścia-wyjścia na dysku, wykryty przez serwer SQL.

Co oznacza komunikat SQL Server 823

Error 823 w Microsoft SQL Server oznacza, że podczas operacji wejścia-wyjścia system operacyjny zwrócił błąd, którego silnik bazy danych nie mógł poprawnie obsłużyć. Komunikat jest zapisywany w dzienniku błędów SQL Server i zwykle zawiera kod błędu systemu Windows, rodzaj operacji, przesunięcie w pliku oraz pełną ścieżkę do pliku bazy danych albo pliku dziennika transakcji. Przesunięcie wskazuje miejsce w pliku, przy którym wystąpiła nieudana próba odczytu lub zapisu.

Nie jest to błąd składni zapytania ani informacja o niepoprawnych danych wpisanych przez użytkownika. Error 823 sygnalizuje problem na niższym poziomie: z urządzeniem przechowującym pliki, kontrolerem, sterownikiem, połączeniem z macierzą, systemem plików albo samym systemem operacyjnym. Przyczyną może być również chwilowa niedostępność zasobu, uszkodzony sektor, błąd transmisji lub nieprawidłowe działanie oprogramowania obsługującego warstwę pamięci masowej.

Różnica między błędami 823, 824 i 825

W diagnostyce SQL Server warto odróżnić Error 823 od podobnych komunikatów. Błąd 823 dotyczy błędu wejścia-wyjścia zwróconego przez system operacyjny. Błąd 824 oznacza, że SQL Server otrzymał odpowiedź wskazującą na logiczną niespójność strony danych, na przykład nieprawidłową sumę kontrolną, niezgodność numeru strony albo inny problem z zawartością strony. Błąd 825 informuje natomiast o pomyślnym ponowieniu operacji odczytu po wcześniejszych nieudanych próbach. Taki komunikat nie musi jeszcze oznaczać utraty danych, ale wskazuje na niebezpieczną niestabilność podsystemu dyskowego.

Sam numer 823 nie określa dokładnie uszkodzonego elementu. Do interpretacji potrzebny jest pełny wpis z dziennika SQL Server, zwłaszcza kod błędu systemu operacyjnego i nazwa pliku. Ten sam kod SQL Server może pojawić się przy różnych problemach sprzętowych lub systemowych. Znaczenie ma także to, czy błąd dotyczy pliku danych z rozszerzeniem .mdf lub .ndf, czy dziennika transakcji .ldf, oraz czy pojawia się jednorazowo, czy powtarza się przy kolejnych operacjach.

Ustalenie źródła awarii w warstwie pamięci masowej

Pierwszym krokiem jest zabezpieczenie aktualnego stanu i odczytanie pełnego komunikatu z ERRORLOG-a SQL Server oraz Podglądu zdarzeń systemu Windows. Należy porównać czas wystąpienia błędu z komunikatami dotyczącymi dysku, kontrolera, sterownika, systemu plików i urządzeń magazynujących. W środowisku korzystającym z macierzy, sieciowej pamięci masowej lub warstwy pośredniej trzeba sprawdzić również dzienniki tej infrastruktury. Nie należy zakładać, że przyczyną jest sam plik bazy tylko dlatego, że jego ścieżka znajduje się w komunikacie.

Po ustaleniu zakresu problemu wykonuje się kontrolę spójności bazy poleceniem DBCC CHECKDB (N'NazwaBazy') WITH NO_INFOMSGS. Polecenie służy do wykrywania uszkodzeń struktur bazy danych, ale nie naprawia awarii sprzętu ani nie zastępuje sprawdzenia dysku. Jeżeli podsystem pamięci masowej nadal zwraca błędy, kolejne operacje odczytu i zapisu mogą pogłębić problem. Wynik DBCC CHECKDB należy zachować w całości, ponieważ komunikaty o uszkodzonych obiektach, stronach i poziomie naprawy są potrzebne do oceny dalszych działań.

Warto także ustalić, na którym woluminie znajdują się pliki bazy i jak wygląda jego dostępne miejsce, stan systemu plików oraz kondycja urządzenia. Narzędzia producenta dysku lub macierzy mogą wykazać błędy nośnika, temperaturę, problemy z łącznością albo zużycie komórek pamięci. Aktualizacja sterownika, firmware’u lub konfiguracji może być uzasadniona dopiero po zebraniu dowodów i sprawdzeniu zgodności z używaną wersją SQL Server. Bez kopii zapasowych i potwierdzonego źródła problemu nie powinno się usuwać plików bazy, zmieniać ich nazw ani wykonywać przypadkowych operacji naprawczych.

Odtwarzanie bazy po błędzie odczytu lub zapisu

Jeżeli kontrola wykazuje uszkodzenie lub wystąpiło ryzyko utraty danych, podstawową metodą odzyskania poprawnego stanu jest odtworzenie bazy z prawidłowych kopii zapasowych. Należy zweryfikować dostępność pełnej kopii, kopii różnicowych oraz kopii dziennika transakcji, jeżeli model odzyskiwania i przyjęta procedura je wykorzystują. Odtwarzanie powinno odbywać się na sprawnym zasobie dyskowym, po usunięciu przyczyny błędu 823. Przywrócenie bazy na ten sam uszkadzający się wolumin może doprowadzić do ponownego wystąpienia problemu.

Nie należy traktować DBCC CHECKDB z opcjami naprawczymi jako równoważnika odtworzenia z kopii zapasowej. Opcje takie jak REPAIR_ALLOW_DATA_LOSS mogą usuwać uszkodzone elementy, aby przywrócić spójność struktur, lecz ich użycie może oznaczać utratę części danych i wymaga świadomej decyzji po analizie wyników. W pierwszej kolejności trzeba zachować kopie plików, dzienniki oraz wyniki diagnostyki, a następnie ustalić, czy możliwe jest pełne odtworzenie danych z kopii.

W przypadku komputera używanego do pracy z lokalną bazą SQL Server diagnostyka powinna objąć stan dysku, połączenia i przewody, kontroler pamięci masowej, sterowniki oraz system plików, a także poprawność kopii zapasowych. Błąd 823 nie powinien być kasowany wyłącznie przez ponowne uruchomienie usługi. Restart może chwilowo przerwać objawy, ale nie usuwa fizycznej przyczyny nieudanego wejścia-wyjścia ani nie potwierdza, że wszystkie strony bazy są poprawne.