В предишната си статия относно сигналите за агент на SQL Server предоставих инструкции стъпка по стъпка как да настроите и конфигурирате сигнали на SQL Agent за грешки с висока сериозност 19-25, както и грешка 825. В тази статия ще обсъдете подробно тези грешки и споделете какво трябва да направите, ако се случат във вашата среда.
Грешки с ниво на сериозност 19 или по-високо спират завършването на текущата партида. Грешки с тежест 20 и по-висока са фатални грешки и прекратяват текущата клиентска връзка. Тези грешки могат също да повлияят на всички процеси в базата данни. Фаталните грешки са точно това, което подсказва името:изпълняваният процес се прекратява и клиентската връзка се затваря.
Грешки със степен на сериозност 19
Грешка с тежест 19 е грешка поради липса на ресурс. Това означава, че вътрешно ограничение (което не можете да конфигурирате) е надвишено и е причинило края на текущата партида. Тези грешки се появяват рядко и няма какво да направите, за да коригирате проблема. Ако възникне грешка с тежест 19, трябва да се свържете с вашия основен доставчик на поддръжка; обикновено това е Microsoft.
През всичките ми години на работа със SQL Server не мога да си спомня нито един инцидент, при който да е генерирана грешка с тежест 19. Дори при търсене в Bing имах проблеми с намирането на възникване на грешката; малкото препратки, които открих, бяха свързани с ранна версия на SQL Server и препращаха към грешка в самия SQL Server.
Грешки със степен на сериозност 20
Грешка с тежест 20 е фатална грешка в текущия процес. Това показва, че даден израз е срещнал проблем и е бил прекратен. Тъй като това засяга само текущия процес, е много малко вероятно самата база данни да е била повредена. Тези грешки са свързани с отделно изявление, така че ще трябва да съберете цялото съобщение за грешка и да се свържете с лицето или екипа, отговорен за този бит код. Това може да бъде вътрешно или евентуално доставчикът на приложението. Примерна грешка е:
Грешка:18056, сериозност 20, състояние:29Клиентът не можа да използва повторно сесия със SPID 123, който беше нулиран за обединяване на връзки.
За тази грешка бих се обърнал към разработчика или доставчика на приложението, тъй като грешката е свързана с обединена връзка, която среща грешка при опит за нулиране. Бих прегледал също регистрационните файлове на SQL Server, които може да имат по-подробно съобщение за грешка относно това, което всъщност се случва, за да причини грешката.
Грешки със степен на сериозност 21
Грешка с тежест 21 е фатална грешка в базата данни, която засяга всички процеси, използващи тази база данни.
Виждал съм тази грешка да се появява при опит за възстановяване на база данни с помощта на функции Enterprise към екземпляр на Standard Edition, както и когато базата данни е повредена и потребителят се опитва да получи достъп до повредена страница. Примерно съобщение за грешка от този тип е:
Грешка:605, сериозност:21, състояние 1Опит за извличане на логическа страница (1:8574233) в база данни 'DB_NAME' принадлежи на обект '0', а не на обект 'Table01'.
Когато се опитвате да възстановите база данни, която използва функции Enterprise, към екземпляр на Standard Edition, първо ще трябва да премахнете Enterprise функциите. Например, ако използвате компресиране на данни или промените улавянето на данни, първо ще трябва да спрете използването и да премахнете тези функции от базата данни, да архивирате базата данни и след това да я възстановите в екземпляра на Standard Edition. Можете да използвате DMV sys.dm_db_persisted_sku_features за да проверите дали използвате функции само за предприятия.
За грешките за повреда ще трябва да изпълните DBCC CHECKDB за да се определи степента на корупцията и да се премине оттам. Ако имате късмет, грешката ще бъде в неклъстериран индекс, който можете да възстановите и да разрешите проблема. Ако повредата е по-сериозна, може да търсите операция за възстановяване. За да разберете по-добре корупцията и как да разрешите различни аспекти на корупцията, ви препоръчвам да прегледате различните публикации в блога на Пол Рандъл. Пол има цяла категория за корупцията, която можете да видите тук:
- http://www.sqlskills.com/blogs/paul/category/corruption/
Изпълнява се DBCC CHECKDB като част от редовно планирана работа срещу вашите бази данни е силно препоръчително за откриване на корупция възможно най-рано. Ако не проверявате редовно за повреда, тогава сте изложени на огромен риск да не успеете да възстановите повредените данни.
Грешки със степен на сериозност 22
Грешка с тежест 22 е фатална грешка поради съмнение за целостта на таблицата, което основно показва, че таблицата или индексът, посочени в съобщението, са повредени. Корупцията се случва и се случва често. Нашият опит е, че по-голямата част от корупцията се дължи на проблем, свързан с I/O подсистемата. Ако попаднете на грешка с тежест 22, ще трябва да изпълните DBCC CHECKDB за определяне на размера на щетите. Примерна грешка е:
Не можа да се отвори XYZ за невалиден идентификатор на файл ## в базата данни. Таблицата или базата данни може да са повредени.
Ако грешката е в неклъстериран индекс, тогава можете просто да възстановите индекса и да коригирате повредата. Ако повредата е в купчина или клъстериран индекс, тогава ще трябва да възстановите базата данни до последователно състояние.
Виждал съм доклади, където повредата е била в паметта, но не и на диска. В този случай рестартирането на екземпляра или настройката на базата данни офлайн и след това онлайн трябва да изчисти грешката.
Грешки със степен на сериозност 23
Грешка с тежест 23 е друга фатална грешка, която съобщава, че самата база данни има проблем с целостта. Разделителната способност е много подобна на грешка с тежест 22, при която трябва незабавно да стартирате DBCC CHECKDB за да откриете пълния размер на щетите в базата данни.
Това ниво на корупция се открива като засягащо цялата база данни. Това може да е повреда в самия файл с данни или повреда в регистрационния файл. Подробностите за грешката ще ви насочат към основния проблем. Например, следната грешка сочи, че ще трябва да възстановим нашата база данни или да се опитаме да изградим отново дневника. За последователност бих възстановил от последното си архивиране и всички налични резервни копия на регистрационния файл на транзакциите.
Грешка:9004, сериозност:23 състояние:6Възникна грешка при обработката на регистрационния файл за база данни „db_name“. Ако е възможно, възстановете от резервно копие. Ако резервното копие не е налично, може да се наложи да изградите отново дневника.
Грешки със степен на сериозност 24
Грешка с тежест 24 е фатална грешка, свързана с хардуер. Това съобщение ще се появи поради някакъв вид срив в медиите. Най-честите от тези типове грешки, които съм виждал, са свързани с проблеми с паметта и I/O грешки. Например:
Грешка:832, сериозност:24, състояние:1Променена е страница, която трябваше да е постоянна (очаквана контролна сума:<очаквана стойност>, действителна контролна сума:<действителна стойност>, база данни
Когато възникнат грешки като тази, трябва да се свържете с вашия екип за поддръжка на системата, за да извършите тест на паметта на вашия сървър и да извършите добра проверка на състоянието на сървъра. Тази грешка може да е лоша памет или драскач на паметта (процес на ядрото или нещо, което променя паметта на SQL Server).
Друг пример:
Грешка:824, сериозност:24, състояние:2SQL сървърът откри I/O грешка, базирана на логическа последователност:неправилен идентификатор на страницата (очаквано 1:123; действително 0:0). Това се случи по време на четене на страница (1:123) в база данни с идентификатор
Тази грешка показва грешка в последователността в основния файл с данни на базата данни. Ще трябва незабавно да стартирате DBCC CHECKDB за да определите степента на повреда и да предприемете съответните действия за поправка или възстановяване на базата данни.
Грешки със степен на сериозност 25
Грешка с тежест 25 е фатална системна грешка. Чувал съм, че тежест 25 е повече или по-малко универсална за различни фатални грешки. Виждал съм тази грешка само когато е свързана с неуспешни надстройки:нещо пречи на един от скриптовете за надстройка да се изпълнява и се извежда грешка с тежест 25. Ще получите грешка, подобна на:
Надстройката на ниво скрипт за базата данни „главен“ не бе успешно, тъй като стъпката на надстройка „sqlagent90_sysdbupg.sql“ срещна грешка 598, състояние 1, сериозност 25. Това е сериозно състояние на грешка, което може да попречи на редовната работа и базата данни ще бъде изведена офлайн. Ако грешката е възникнала по време на надстройката на 'главната' база данни, тя ще попречи на стартирането на целия екземпляр на SQL Server. Проверете предишните записи в регистъра за грешки за грешки, предприемете съответните коригиращи действия и рестартирайте базата данни, така че стъпките за надграждане на скрипта да изпълнят до завършване.В този случай грешките преди това съобщение показват неправилен път за местоположението на данните по подразбиране за SQL Server. След като това беше коригирано, надстройката премина успешно.
Грешка 825
Грешка 825 често се нарича предупреждение за повторен опит за четене, но условието е както за операции за четене, така и за запис. Тази грешка ви позволява да знаете, че е бил необходим повторен опит на операцията и колко пъти SQL Server е трябвало да опита отново, преди да бъде успешен. SQL Server ще опита отново операциите до четири пъти, след четири опита за повторен опит ще изведе грешка 823 или 824. Съобщенията за грешка 825 ще бъдат подобни на следните:
Четенето на файла „път към име на файла\db_name.mdf“ при отместване 0x00000002000 беше успешно след неуспешен 2 пъти(и) с грешка:неправилна контролна сума (очаквано:XYZ; действителен ABC). Допълнителните съобщения в регистъра за грешки на SQL Server и регистъра на системните събития може да предоставят повече подробности. Това състояние на грешка заплашва целостта на базата данни и трябва да бъде коригирано. Извършете пълна проверка на последователността на базата данни (DBCC CHECKDB). Тази грешка може да бъде причинена от много фактори; за повече информация вижте SQL Server Books Online.
Тези съобщения са важни, тъй като показват, че имате по-голям проблем с вашата дискова подсистема. Методите за отстраняване на неизправности са да се изпълни DBCC CHECKDB за да се уверите, че базата данни е последователна, както препоръчва грешката, както и да прегледате регистрите на събития на Windows за грешки от операционната система или устройствата за съхранение. Трябва да накарате вашия екип за поддръжка и хардуер да прегледа и основната I/O подсистема за грешки.
Резюме
Конфигурирането на сигнали за SQL агент е безплатно и лесно. Да бъдеш проактивен и да реагираш на тези сигнали е важно, за да сведеш до минимум времето за престой за вас и вашите клиенти. Както вече научихте, много неща могат да повлияят на SQL Server и последователността на вашите бази данни, а най-добрата защита за възстановяване от тези грешки е да имате добри архиви и да знаете различните опции за поправка за DBCC CHECKDB . Винаги се препоръчва да изпълнявате DBCC CHECKDB редовно срещу вашите бази данни, за да откриете повреда възможно най-рано, тъй като колкото по-бързо откриете корупцията, толкова по-вероятно е данните да бъдат архивирани, така че да можете да ги възстановите без загуба на данни.
