Error 824 – niespójność logiczna danych

Error 824, opisany jako niespójność logiczna danych, to pełne, opisowe określenie tego samego błędu uszkodzenia strony bazy.

Error 824 w silniku Microsoft SQL Server

Error 824 w Microsoft SQL Server oznacza błąd wejścia-wyjścia, podczas którego odczytana strona danych nie spełnia oczekiwanej spójności logicznej. Silnik otrzymał odpowiedź z podsystemu dyskowego, ale zawartość strony nie odpowiada strukturze, metadanym albo regułom integralności wymaganym dla strony SQL Server. Jest to odmienna sytuacja od błędu 823, który wskazuje przede wszystkim na fizyczne niepowodzenie operacji wejścia-wyjścia. W przypadku błędu 824 urządzenie może zgłosić pomyślne zakończenie odczytu, lecz SQL Server wykrywa, że zwrócone dane są nieprawidłowe.

Komunikat zwykle zawiera numer bazy danych, numer pliku, identyfikator strony oraz dodatkowe informacje o rodzaju naruszonej spójności. Identyfikator strony jest zapisywany w formacie file:page, na przykład 1:12345, gdzie pierwsza liczba oznacza plik danych, a druga numer strony w tym pliku. Standardowa strona danych SQL Server ma rozmiar 8 KiB, natomiast obszar kontrolny strony zawiera informacje wykorzystywane przez silnik do rozpoznania jej typu, identyfikacji oraz stanu. Szczegółowy opis błędu należy zachować z dziennika błędów, ponieważ pozwala powiązać komunikat z konkretnym fragmentem pliku bazy.

Jak powstaje niespójność logiczna strony

SQL Server zapisuje na stronach danych informacje, które umożliwiają wykrywanie uszkodzeń lub niezgodności strukturalnych. W zależności od konfiguracji bazy może być używana suma kontrolna strony, czyli mechanizm page checksum. Suma kontrolna pozwala stwierdzić, że zawartość strony zmieniła się w sposób niezgodny z wartością obliczoną podczas zapisu. Sam Error 824 nie powinien jednak być automatycznie utożsamiany wyłącznie z uszkodzoną sumą kontrolną. Komunikat może dotyczyć także innych naruszeń logicznej struktury strony, takich jak nieprawidłowe wartości pól systemowych, błędny identyfikator strony lub niespodziewany typ strony.

Źródłem problemu może być wadliwy nośnik danych, kontroler pamięci masowej, sterownik, firmware urządzenia, niestabilne połączenie albo błąd warstwy buforowania. Uszkodzenie może również ujawnić się dopiero podczas odczytu strony, która została wcześniej zapisana niepoprawnie. Błąd nie dowodzi sam w sobie, że uszkodzony jest cały plik MDF lub cała baza. Oznacza natomiast, że konkretnego odczytu nie można traktować jako wiarygodnego i że należy sprawdzić zarówno wskazaną bazę, jak i infrastrukturę przechowywania danych.

Postępowanie po wykryciu błędu 824

Pierwszym krokiem jest zabezpieczenie pełnych komunikatów z dziennika błędów SQL Server oraz dziennika systemowego Windows. Warto odnotować czas wystąpienia, nazwę bazy, numer pliku, numer strony i ewentualne kolejne błędy 823, 824 lub 825. Następnie wykonuje się kontrolę spójności za pomocą polecenia DBCC CHECKDB, na przykład DBCC CHECKDB (N'NazwaBazy') WITH NO_INFOMSGS, ALL_ERRORMSGS;. Polecenie analizuje logiczną i fizyczną spójność obiektów bazy, ale nie powinno być przerywane bez potrzeby, ponieważ zakres i czas kontroli zależą od rozmiaru bazy oraz rodzaju wykrytych struktur.

Informacje o podejrzanych stronach mogą być rejestrowane w tabeli msdb.dbo.suspect_pages. Sama obecność wpisu w tej tabeli nie zastępuje pełnej kontroli DBCC CHECKDB, lecz pomaga ustalić, które strony zgłaszały problemy. Nie należy rozpoczynać od poleceń naprawczych z opcją REPAIR_ALLOW_DATA_LOSS. Taka opcja może usunąć uszkodzone elementy, aby przywrócić formalną spójność struktury, ale potencjalnie powoduje utratę danych. Preferowanym sposobem odzyskania uszkodzonej strony lub obiektu jest odtworzenie bazy z wiarygodnej kopii zapasowej, ewentualnie z wykorzystaniem kopii pełnej, różnicowej i dzienników transakcji, jeśli dostępny łańcuch kopii pozwala na takie odtworzenie.

Weryfikacja bazy, kopii i podsystemu dyskowego

Po wystąpieniu Error 824 sama naprawa logiczna nie zamyka sprawy. Trzeba ustalić, czy problem dotyczy pojedynczej strony, większego zakresu pliku, konkretnego woluminu czy całej ścieżki wejścia-wyjścia. Kontrola powinna obejmować stan dysków, macierzy lub innego magazynu, komunikaty kontrolera, sterowniki, firmware oraz błędy systemu plików. Należy także sprawdzić, czy kopie zapasowe można rzeczywiście odtworzyć i zweryfikować. Przydatne jest okresowe wykonywanie RESTORE VERIFYONLY, jednak poprawny wynik tego polecenia nie zastępuje odtworzenia testowego ani kontroli spójności zawartości bazy.

Jeżeli DBCC CHECKDB wskazuje uszkodzone strony, dalsze działania powinny wynikać z dokładnego raportu i wartości danych. W niektórych przypadkach można odtworzyć pojedynczą stronę z kopii zapasowej strony, jeżeli taka kopia została wykonana i spełnia wymagania danej konfiguracji. W innych sytuacjach konieczne jest odtworzenie całej bazy lub analiza możliwości eksportu nieuszkodzonych danych do nowej bazy. Diagnostyka błędu 824 powinna być prowadzona z zachowaniem oryginalnych plików bazy, kopii zapasowych i pełnej historii komunikatów.