W moim poprzednim artykule na temat alertów agenta programu SQL Server przedstawiłem instrukcje krok po kroku, jak skonfigurować i skonfigurować alerty agenta programu SQL dla błędów o wysokim poziomie ważności 19-25 oraz błędu 825. W tym artykule zamierzam Omów szczegółowo te błędy i podziel się tym, co powinieneś zrobić, jeśli wystąpią w Twoim środowisku.
Błędy o poziomie istotności 19 lub wyższym uniemożliwiają ukończenie bieżącej partii. Błędy o wadze 20 i wyższej są błędami krytycznymi i przerywają bieżące połączenie klienta. Błędy te mogą również wpływać na wszystkie procesy w bazie danych. Błędy krytyczne są dokładnie tym, co sugeruje nazwa:uruchomiony proces zostaje zakończony, a połączenie klienta zamknięte.
Błędy o wadze 19
Błąd poziomu 19 jest błędem spowodowanym brakiem zasobu. Oznacza to, że limit wewnętrzny (którego nie możesz skonfigurować) został przekroczony i spowodował zakończenie bieżącej partii. Te błędy występują rzadko i niewiele można zrobić, aby rozwiązać problem. W przypadku wystąpienia błędu o wadze 19 należy skontaktować się z głównym dostawcą pomocy technicznej; zazwyczaj byłby to Microsoft.
Przez wszystkie lata pracy z SQL Serverem nie przypominam sobie żadnego incydentu, w którym został wygenerowany błąd o powadze 19. Nawet przeszukując Bing, miałem problem ze znalezieniem wystąpienia błędu; kilka odniesień, które znalazłem, dotyczyło wczesnej wersji SQL Server i odnosiło się do błędu w samym SQL Server.
Błędy o poziomie ważności 20
Błąd poziomu 20 jest krytycznym błędem w bieżącym procesie. Oznacza to, że instrukcja napotkała problem i została zakończona. Ponieważ ma to wpływ tylko na bieżący proces, jest bardzo mało prawdopodobne, że sama baza danych została uszkodzona. Błędy te są powiązane z indywidualną instrukcją, więc musisz zebrać cały komunikat o błędzie i skontaktować się z osobą lub zespołem odpowiedzialnym za ten fragment kodu. Może to być firma wewnętrzna lub ewentualnie dostawca aplikacji. Przykładowy błąd to:
Błąd:18056, wskaźnik ważności 20, stan:29Klient nie mógł ponownie użyć sesji o identyfikatorze SPID 123, która została zresetowana do puli połączeń.
W przypadku tego błędu skontaktowałbym się z deweloperem lub dostawcą aplikacji, ponieważ błąd jest związany z połączeniem w puli, które napotyka błąd podczas próby zresetowania. Chciałbym również przejrzeć dzienniki SQL Server, które mogą zawierać bardziej szczegółowy komunikat o błędzie dotyczący tego, co faktycznie powoduje błąd.
Błędy o poziomie ważności 21
Błąd poziomu 21 jest krytycznym błędem w bazie danych, który wpływa na wszystkie procesy korzystające z tej bazy danych.
Widziałem ten błąd podczas próby przywrócenia bazy danych przy użyciu funkcji Enterprise do instancji Standard Edition, a także gdy baza danych jest uszkodzona, a użytkownik próbuje uzyskać dostęp do uszkodzonej strony. Przykładowy komunikat o błędzie tego typu to:
Błąd:605, wskaźnik ważności:21, stan 1Próba pobrania strony logicznej (1:8574233) w bazie danych „DB_NAME” należy do obiektu „0”, a nie do obiektu „Table01”.
Podczas próby przywrócenia bazy danych korzystającej z funkcji Enterprise do instancji Standard Edition, należy najpierw usunąć funkcje Enterprise. Na przykład, jeśli używasz kompresji danych lub zmiany przechwytywania danych, najpierw musisz przestać używać i usunąć te funkcje z bazy danych, utworzyć kopię zapasową bazy danych, a następnie przywrócić ją do instancji Standard Edition. Możesz użyć DMV sys.dm_db_persisted_sku_features aby sprawdzić, czy korzystasz z funkcji tylko dla przedsiębiorstw.
W przypadku błędów korupcji musisz uruchomić DBCC CHECKDB by określić zakres zepsucia i stamtąd wyjść. Jeśli masz szczęście, błąd będzie dotyczył indeksu nieklastrowanego, który można odbudować i rozwiązać problem. Jeśli uszkodzenie jest poważniejsze, możesz przyglądać się operacji przywracania. Aby lepiej zrozumieć korupcję i jak rozwiązać różne aspekty korupcji, zachęcam do przejrzenia różnych postów na blogu autorstwa Paula Randala. Paul ma całą kategorię dotyczącą korupcji, którą możesz zobaczyć tutaj:
- http://www.sqskills.com/blogs/paul/category/corruption/
Uruchamianie DBCC CHECKDB w ramach regularnie zaplanowanego zadania w bazach danych jest wysoce zalecane, aby jak najszybciej wykryć uszkodzenie. Jeśli nie sprawdzasz regularnie pod kątem uszkodzeń, istnieje ogromne ryzyko, że nie będziesz w stanie odzyskać uszkodzonych danych.
Błędy o wadze 22
Błąd poziomu 22 jest błędem krytycznym ze względu na podejrzenie integralności tabeli, co oznacza, że tabela lub indeks określony w komunikacie jest uszkodzony. Korupcja zdarza się i zdarza często. Z naszego doświadczenia wynika, że większość korupcji występuje z powodu problemu związanego z podsystemem I/O. Jeśli napotkasz błąd o wadze 22, musisz uruchomić DBCC CHECKDB w celu określenia rozmiaru szkody. Przykładowy błąd to:
Nie można otworzyć XYZ dla nieprawidłowego identyfikatora pliku ## w bazie danych. Tabela lub baza danych może być uszkodzona.
Jeśli błąd dotyczy indeksu nieklastrowanego, możesz po prostu odbudować indeks i naprawić uszkodzenie. Jeśli uszkodzenie dotyczy stosu lub indeksu klastrowego, konieczne będzie przywrócenie bazy danych do spójnego stanu.
Widziałem raporty, w których uszkodzenie znajdowało się w pamięci, ale nie na dysku. W takim przypadku ponowne uruchomienie instancji lub ustawienie bazy danych w trybie offline, a następnie online powinno usunąć błąd.
Błędy o wadze 23
Błąd poziomu 23 to kolejny błąd krytyczny, który informuje, że sama baza danych ma problem z integralnością. Rozwiązanie jest bardzo podobne do błędu wagi 22, w którym musisz natychmiast uruchomić DBCC CHECKDB znaleźć pełny zakres uszkodzenia bazy danych.
Ten poziom uszkodzenia jest wykrywany jako wpływ na całą bazę danych. Może to być uszkodzenie samego pliku danych lub uszkodzenie pliku dziennika. Szczegóły błędu skierują Cię w stronę głównego problemu. Na przykład następujący błąd wskazuje, że musielibyśmy przywrócić naszą bazę danych lub spróbować odbudować dziennik. Aby zachować spójność, przywróciłbym z najnowszej kopii zapasowej i wszystkich dostępnych kopii zapasowych dziennika transakcji.
Błąd:9004, Istotność:23 Stan:6Wystąpił błąd podczas przetwarzania dziennika bazy danych 'db_name'. Jeśli to możliwe, przywróć z kopii zapasowej. Jeśli kopia zapasowa nie jest dostępna, może być konieczne odbudowanie dziennika.
Błędy ważności 24
Błąd poziomu 24 jest krytycznym błędem związanym ze sprzętem. Ten komunikat pojawi się z powodu jakiegoś rodzaju awarii nośnika. Najczęstsze z tych rodzajów błędów, które widziałem, są związane z problemami z pamięcią i błędami we/wy. Na przykład:
Błąd:832, Ważność:24, Stan:1Strona, która powinna być stała, uległa zmianie (oczekiwana suma kontrolna:
Gdy wystąpią takie błędy, należy skontaktować się z zespołem wsparcia systemu, aby przeprowadzić test pamięci na serwerze i zapewnić serwerowi dobrą kontrolę stanu. Ten błąd może dotyczyć złej pamięci lub bazgrołów pamięci (proces jądra lub coś, co zmienia pamięć SQL Server).
Inny przykład:
Błąd:824, wskaźnik ważności:24, stan:2program SQL Server wykrył błąd we/wy oparty na spójności logicznej:niepoprawny identyfikator strony (oczekiwano 1:123; rzeczywiste 0:0). Wystąpiło to podczas odczytów strony (1:123) w bazie danych o identyfikatorze
Ten błąd wskazuje na błąd spójności w podstawowym pliku danych bazy danych. Musisz natychmiast uruchomić DBCC CHECKDB w celu określenia zakresu uszkodzenia i podjęcia odpowiednich działań w celu naprawy lub przywrócenia bazy danych.
Błędy o wadze 25 ważności
Błąd poziomu 25 jest krytycznym błędem systemu. Słyszałem, że dotkliwość 25 jest mniej więcej ogólnym hasłem dla różnych fatalnych błędów. Widziałem ten błąd tylko w przypadku nieudanych aktualizacji:coś uniemożliwia uruchomienie jednego ze skryptów aktualizacji i zgłaszany jest błąd o wadze 25. Otrzymasz błąd podobny do:
Uaktualnienie na poziomie skryptu dla bazy danych „master” nie powiodło się, ponieważ krok uaktualniania „sqlagent90_sysdbupg.sql” napotkał błąd 598, stan 1, poziom ważności 25. Jest to poważny stan błędu, który może zakłócać normalne działanie i baza danych zostanie przeniesiona do trybu offline. Jeśli błąd wystąpił podczas aktualizacji bazy danych „master”, uniemożliwi to uruchomienie całej instancji SQL Server. Sprawdź poprzednie wpisy dziennika błędów pod kątem błędów, podejmij odpowiednie działania naprawcze i ponownie uruchom bazę danych, tak aby kroki aktualizacji skryptu zostały zakończone.W takim przypadku błędy poprzedzające ten komunikat wskazywały niepoprawną ścieżkę do domyślnej lokalizacji danych dla programu SQL Server. Po naprawieniu uaktualnienie przebiegło pomyślnie.
Błąd 825
Błąd 825 jest często określany jako ostrzeżenie o ponownej próbie odczytu, jednak warunek dotyczy zarówno operacji odczytu, jak i zapisu. Ten błąd informuje, że potrzebna była ponowna próba operacji i ile razy SQL Server musiał ponowić próbę, zanim się powiodła. SQL Server ponawia operację do czterech razy, po czterech ponownych próbach zgłosi błąd 823 lub 824. Komunikaty o błędach 825 będą podobne do następujących:
Odczyt pliku „ścieżka do nazwy pliku\db_name.mdf” pod offsetem 0x00000002000 powiódł się po dwóch nieudanych próbach wystąpienia błędu:nieprawidłowa suma kontrolna (oczekiwana:XYZ; rzeczywiste ABC). Dodatkowe komunikaty w dzienniku błędów programu SQL Server i dzienniku zdarzeń systemowych mogą zawierać więcej szczegółów. Ten stan błędu zagraża integralności bazy danych i należy go naprawić. Wykonaj pełną kontrolę spójności bazy danych (DBCC CHECKDB). Ten błąd może być spowodowany wieloma czynnikami; Aby uzyskać więcej informacji, zobacz SQL Server Books Online.
Te komunikaty są ważne, ponieważ wskazują, że masz większy problem z podsystemem dysku. Metody rozwiązywania problemów to uruchomienie DBCC CHECKDB aby upewnić się, że baza danych jest spójna, zgodnie z zaleceniami błędu, a także przejrzyj dzienniki zdarzeń systemu Windows pod kątem błędów systemu operacyjnego lub urządzeń pamięci masowej. Powinieneś poprosić zespół wsparcia pamięci masowej i sprzętu o sprawdzenie podstawowego podsystemu we/wy pod kątem błędów.
Podsumowanie
Skonfigurowanie alertów SQL Agent jest bezpłatne i łatwe. Proaktywność i reagowanie na te alerty jest ważne, aby zminimalizować przestoje dla Ciebie i Twoich klientów. Jak już wiesz, wiele rzeczy może wpłynąć na SQL Server i spójność baz danych, a najlepszą ochroną przed naprawą tych błędów jest posiadanie dobrych kopii zapasowych i znajomość różnych opcji naprawy DBCC CHECKDB . Zawsze zaleca się uruchomienie DBCC CHECKDB regularnie w swoich bazach danych, aby jak najszybciej wykryć uszkodzenie, ponieważ im szybciej je znajdziesz, tym większe prawdopodobieństwo, że masz kopię zapasową danych, aby można było przywrócić dane bez utraty danych.
