Въведение
Редовната поддръжка на база данни е важна част от работата на администратора на база данни, която помага да се гарантира, че критично важните системи работят нормално. Един от най-лесните начини да постигнете това ще бъде автоматизирането на задачи, свързани с DBCC CheckDB. Без значение каква версия на SQL Server използвате, никога няма да има база данни, която не изисква поддръжка. Ще трябва да планирате поддръжката да се извършва редовно, за да можете да покриете гърба си, особено по време на реален сценарий на бедствие.
DBA винаги е виновникът
Винаги, когато има проблем с базата данни, всички очи са насочени към DBA. Независимо дали проблемът е бил причинен от дъжд или поради това, че някой разработчик пише неприятен код, водещ до забавяне на базата данни, DBA винаги се очаква да поправи бъркотията. И можете да си представите какъв натиск трябва да се справите, ако бъдете помолени бързо да възстановите база данни, като използвате последното налично архивно копие, което, както ще разберете в процеса, не е валидно и целостта на базата данни вече е била компрометирана няколко месеца преди. Тук се крие разликата между проактивен DBA и реактивен DBA. В действителност стратегията ви за възстановяване е много по-критична в сравнение със стратегията за архивиране. Каква цел може да служи ежедневното архивиране на база данни, ако не е от полза по време на възстановяване?
Защо поддръжката е важна?
С безпрецедентния растеж на технологиите за бази данни и с нови функции, които се появяват с всяка версия, за вас като администратор на база данни е наложително да останете пред останалите и да се уверите, че следвате най-добрите практики в индустрията в поддръжка на база данни.
DBCC CheckDB и как можем да го стартираме
DBCC CheckDB – това име е доста описателно за функционалността. Казано с прости думи, той проверява бази данни. Това е важно, за да се гарантира, че базата данни работи според очакванията. По принцип DBCC CheckDB проверява логическата и физическата цялост на всички обекти в базата данни. Това е, което DBCC CheckDB прави под капака според официалното Документация на Microsoft:
Изпълнява DBCC CHECKALLOC в базата данни – последователността на разпределянето на дисково пространство
Изпълнява DBCC CHECKTABLE на всяка таблица и изглед в базата данни – това е целостта на всички страници и структури, които съставляват таблицата или индексирания изглед.
Изпълнява DBCC CHECKCATALOG в базата данни – това проверява за последователност на каталога в рамките на посочената база данни.
Проверява съдържанието на всеки индексиран изглед в базата данни.
Проверява съгласуваността на ниво връзка между метаданните на таблицата и директориите/файловете на файловата система при съхраняване на varbinary(max) данни във файловата система с помощта на FILESTREAM.
Проверява данните на Service Broker в базата данни.
Когато изпълните командата DBCC CheckDB изрично или чрез задание, тя по същество изпълнява всичко по-горе.
Изпълнение на DBCC CheckDB директно върху база данни
Можете да стартирате командата DBCC CheckDB директно в база данни и да проверите за резултатите. Проверете изхода на командата, както е показано на екранната снимка по-долу. Резултатът показва подробностите за редовете в таблиците и броя на страниците, използвани от тези редове.
Ако погледнете внимателно, ще видите повече подробности, специфични за обектите на базата данни. Например в базата данни „VLDB“ мога да видя следния изход:
“ID на обект 1179151246 (обект „Warehouse.ColdRoomTemperatures“):Операцията не се поддържа с оптимизирани за памет таблици. Този обект е пропуснат и няма да бъде обработен.”
Както показва този изход, DBCC CheckDB не се поддържа с оптимизирани за памет таблици. Оптимизираните за памет таблици за първи път бяха въведени в SQL Server 2014 като функция само за предприятия. Въпреки това, през годините те се превърнаха в популярна и широко разпространена функционалност в SQL Server.
Също така ще забележите, че DBCC Check потвърди данните за брокера на услуги в базата данни, както е показано по-долу.
„Резултати от DBCC за 'VLDB'.Service Broker Msg 9675, State 1:Анализирани типове съобщения:14.Service Broker Msg 9676, State 1:Анализирани договори за услуги:6.Service Broker Msg 9667, State 1:Анализирани услуги:3.Service Broker Msg 9668, състояние 1:Анализирани опашки за услуги:3.Service Broker Msg 9669, състояние 1:Анализирани крайни точки на разговор:0.Service Broker Msg 9674, състояние 1:Анализирани групи за разговори:0.Service Broker Msg, Msg 9670 1:Анализирани обвързвания за отдалечени услуги:0. Съобщение на брокера на услуги 9605, състояние 1:Анализирани приоритети на разговор:0.”
Накрая, след като командата DBCC CheckDB бъде завършена успешно, ще видите следния изход:
Какво се случва, ако се докладват грешки след изпълнение на DBCC CheckDB?
В горния пример можете да видите, че DBCC CheckDB е завършен без никакви грешки. Ако обаче нямате такъв късмет, може да срещнете грешки в последователността – и това ще бъде моментът, когато трябва да вземете някои критични решения. Ако срещнете проблеми в производствена база данни, най-добре е да информирате собствениците на бизнес или вашия оперативен мениджър да постави вашите карти на масата. Можете или да им дадете възможност да възстановят базата данни от последното налично архивно копие, или можете да експериментирате с изпълнение на команди DBCC CheckDB с допълнителни опции.
Съобщенията за грешка в DBCC може да изглеждат нещо като това по-долу:
Грешка в таблицата:идентификатор на обект 36, идентификатор на индекс 1, идентификатор на дял, идентификатор на единица за разпределяне (тип данни в ред). Ключовете не са в ред на страница (1:107), слотове 6 и 9. CHECKDB откри 0 грешки при разпределението и 1 грешки в последователността в таблица 'sys.syk' (идентификатор на обект 36). CHECKDB откри 0 грешки при разпределение и 1 грешка в последователността в базата данни 'VLDB'.repair_rebuild е минималното ниво на поправка за грешките, открити от DBCC CHECKDB (VLDB).В съобщението за грешка можете да видите внимателно формулирано съобщение за грешка – „repair_rebuild е минимум ниво на поправка за грешките, открити от DBCC CHECKDB ” – предлага ви да стартирате DBCC CheckDB с опцията repair_rebuild. Просто погледнете подчертаната дума – „минимум“. Това означава, че с опцията repair_rebuild няма реална възможност за загуба на данни и SQL Server прави някои бързи корекции под капака. Моля, вижте командата по-долу, за да стартирате DBCC CheckDB с опцията repair_rebuild. Уверете се, че сте поставили базата данни в режим на един потребител.
Съгласно документацията на Microsoft, опцията REPAIR_REBUILD е най-безобидната версия, тъй като не може да има загуба на данни. Въпреки това, ако REPAIR_REBUILD все още не коригира грешките в последователността, има още една опция – да активирате REPAIR_ALLOW_DATA_LOSS. Гледайки името, знаем, че би имало възможност за загуба на данни, ако включим тази опция. Поради това Microsoft ни предупреждава да използваме това с изключително внимание, тъй като може да има неочаквани последици при стартиране на DBCC CheckDB с REPAIR_ALLOW_DATA_LOSS. Командата DBCC CheckDB в този случай ще изглежда по следния начин:
Точки, които трябва да имате предвид, преди да използвате опцията Repair с DBCC CheckDB
Колко критична е въпросната база данни?
Базата данни в производствена или тестова среда ли е?
Колко голяма е базата данни?
Имате ли добра стратегия за възстановяване в случай, че се появят проблеми?
Уверихте ли резервните си копия на базата данни?
Въз основа на ситуацията и отговорите на горните въпроси се опитайте да вземете решение, като имате предвид най-добрите интереси на клиента.
Автоматизиране на задачите на DBCC CheckDB на SQL Server с помощта на планове за поддръжка на база данни
Е, не е нужно да изпълнявате всички тези команди ръчно на сървърите си. Ето защо имаме изготвени планове за поддръжка. Уверете се, че планирате редовен цикъл на поддръжка за всичките си бази данни, като използвате плановете за поддръжка на базата данни. Това е доста проста и ясна задача. Под „Задачи на плана за поддръжка“ изберете „Задача за проверка на целостта на базата данни“.
Това ще добави подзадача към вашия план за поддръжка за насрочване на проверки на целостта на вашите бази данни. Уверете се, че сте избрали необходимите бази данни, както е показано.
Моля, не забравяйте да изпълните всички проверки на базата данни по време на непиковото време на седмицата. Обикновено прозорците за поддръжка са през уикендите, когато сървърът е по-малко натоварен в сравнение с другите дни от седмицата. Това обаче ще варира от сървър до сървър и зависи от приложението. При критични системи за бази данни сигналите обикновено се показват винаги, когато има пропуснати DBCC CheckDB или проверки на целостта. По този начин администраторите на база данни могат проактивно да проверяват и да гарантират, че ще приключат проверките за цялост, за да избегнат изненади по-късно.
Автоматизиране на DBCC CheckDB задачи на SQL Server с помощта на персонализирани скриптове или други популярни скриптове
Плановете за поддръжка на SQL Server не е необходимо да се използват през цялото време за изпълнение на задачи за поддръжка на вашия екземпляр на SQL Server. Има и други налични персонализирани скриптове, които можете да използвате. Един от популярните безплатни инструменти за поддръжка е решението за поддръжка на Ola Hallengren. Можете да инсталирате цялото решение за поддръжка, което включва задачи за архивиране, оптимизация и т.н., или можете да изтеглите само съответните скриптове, свързани с проверките на целостта. В тази демонстрация ще се опитаме да инсталираме скриптовете, специфични за проверките на целостта на базата данни.
Щракнете върху опцията DatabaseIntegrityCheck.sql, както е показано, за да изтеглите съхранените процедури, които проверяват целостта на базата данни. След като изпълних тези съхранени процедури в главната база данни, попаднах на следните предупредителни съобщения:
„Модулът „DatabaseIntegrityCheck“ зависи от липсващия обект „dbo.CommandExecute“. Модулът все още ще бъде създаден; обаче не може да работи успешно, докато обектът не съществува.”
Ако стартирате съхранената процедура за извършване на проверки на целостта, ще получите следната грешка:
Както гласи грешката, можете да изтеглите липсващия код тук. След като това стане, можете да започнете да изпробвате проверките на целостта на базата данни.
Можете да регулирате различни опции, като използвате допълнителните параметри на командата DBCC. Можете да намерите повече подробности и примери за тях тук.
В тази демонстрация обаче ще проверим няколко примера, за да видим колко лесни и лесни за използване са всъщност тези скриптове.
За изпълнение на DBCC CheckDB във всички потребителски бази данни , ще трябва да изпълните следното:
EXECUTE dbo.DatabaseIntegrityCheck@Databases ='USER_DATABASES',@CheckCommands ='CHECKDB'
Можете да видите изпълняваната команда и състоянието на резултата, което потвърждава, че DBCC CheckDB е завършил успешно.
За да стартирате DBCC Проверете само за системните бази данни, изпълнете тази команда:
EXECUTE dbo.DatabaseIntegrityCheck@Databases ='SYSTEM_DATABASES',@CheckCommands ='CHECKDB'
На екранната снимка можете да видите, че DBCC CheckDB е завършена успешно за системните бази данни.
За изпълнение на DBCC CheckDB само за конкретна база данни, изпълнете следното:
EXECUTE dbo.DatabaseIntegrityCheck@Databases ='VLDB', -- вашето конкретно DB Name@CheckCommands ='CHECKDB'
В горния пример видяхте няколко начина, по които можем да използваме параметри. Въпреки това, има редица други филтри, които можете да изберете въз основа на вашите предпочитания. Също така, както вече споменахме, можете да се обърнете към тази връзка за по-нататъшно разбиране на сценариите на Ола Халенгрен. Само да повторя, използвам скриптовете на Ola Hallengren на сървърите, които управлявам и е силно препоръчан и признат в общността на SQL Server. Можете да планирате съхранените процедури въз основа на предпочитаните от вас параметри и да ги изпълнявате като SQL задание в непиковите часове. По този начин всъщност не е нужно да изпълнявате нито един от тези скриптове ръчно, за да можете да се съсредоточите върху други важни задачи.
Заключение
- От тази статия научихте за DBCC CheckDB и как може да се използва
- Също така разбрахте колко е важно да изпълнявате DBCC CheckDB редовно във всичките си важни бази данни
- Научихте също за важността да имате изпробвана стратегия за архивиране – препоръчително е да възстановите базите си с помощта на добро архивиране, вместо да разрешавате грешки в последователността с помощта на опциите за поправка на DBCC
- Видяхте също колко лесно е да се конфигурират и автоматизират скриптове чрез планове за поддръжка на SQL Server или персонализирани скриптове, например този от Ola Hallengren
- Научихте също за рисковете да не насрочите DBCC CheckDB на поддържаната от вас инфраструктура
- Научихте също, че независимо на кой сървър сте или каква инфраструктура управлявате, не може да има база данни, която да не изисква поддръжка
- И накрая, уверете се, че поддържате базите си здрави и във всеки случай бъдете готови за онези дни OFF, които може да не са под ваш контрол
