Плановете за поддръжка в SQL Server ни дават лесен начин да организираме, конфигурираме и планираме задачи, които гарантират, че машината на базата данни и базите данни, които се хостват в нея, се поддържат във форма.
Плановете за поддръжка предлагат на администратора на базата данни възможност да конфигурира ключови задачи като индексиране, актуализации на статистиката, архивиране, почистване на регистрационни файлове и други. В предишната статия вече обсъдихме как да създадем основен план за поддръжка за извършване на проверка на последователността на базата данни. В тази статия ще направим пошагово ръководство за създаване на план за поддръжка за екземпляр на база данни, който хоства малки бази данни. В хода на ръководството ще обясня ключовите избори, направени във всяка стъпка в контекста на екземпляр с умерено голям брой малки бази данни. Идеята е да се конфигурира поддръжка за тези бази данни, без да се налага да се прави една по една. Фокусът върху малките бази данни има за цел да избегне излишните разходи за производителност, свързани с операциите по поддръжката.
План за поддръжка за седмични задачи
Фигура 1:Стартирайте съветника за план за поддръжка
Стартираме съветника за планове за поддръжка от Object Explorer>[Име на инстанция]>Управление>Планове за поддръжка (вижте фигура 1). Първата страница на съветника ни дава общ преглед на онези задачи, които могат да бъдат конфигурирани. Въпреки че има други начини за изпълнение на тези задачи с помощта на код и планиране на задания, съветникът за планове за поддръжка го прави доста лесен за изпълнение, когато се работи с голям брой бази данни, хоствани в един екземпляр.
Фигура 2:Съветник за план за поддръжка
На фигура 3 виждаме SQL Server показващи полета, за да назовем и опишем плана за поддръжка. Въвеждането на описание на плана има смисъл за целите на документацията. Представете си, че поемате нов екземпляр на SQL Server в нова компания. Би било полезно, ако намерите описания на обекти на SQL Server в обектите. Вие трябва да направите същото за другите. Моля, имайте предвид, че описанието, което дадох, има за цел просто да илюстрира точката. По-подробно описание ще бъде желателно в производствена среда.
Фигура 3:Именуване на плана за поддръжка
Обърнете внимание, че на фигура 3 имаме възможност да изберем дали искаме да използваме един график за всички задачи или отделен график за всяка задача. Избрах да използвам отделни графици, за да имам гъвкавост при разпределяне на задачите. Не бихме искали твърде много операции по поддръжка да се изпълняват едновременно или последователно в продължение на дълго време, за да избегнем риска от претоварване на сървърните ресурси. Решението, което вземете в този момент, може също да зависи от капацитета на наличните за вас ресурси и наличния прозорец за поддръжка. Някои хора имат достатъчен капацитет и биха искали да свършат задачата бързо по време на всяко изпълнение. В сценария, обхванат от тази статия, приемаме, че въпросният екземпляр не се използва през уикенда.
На фигура 4 избираме задачите, които искаме да изпълним. Едно от страхотните неща за SQL Server е, че всяка задача е описана в долната част на прозореца. Изплаща се, когато работите като DBA, за да разберете какво правите, дори когато работите на „Windows“. Според моя опит много „администратори“ имат навика просто да щракнат върху „СЛЕДВАЩ, СЛЕДВАЩ, СЛЕДВАЩ“, защото бързат да задействат функционалността. Но отделянето на време за разбиране на въздействието на следващото „СЛЕДВАЩО“ помага да се гарантира, че правите нещо, което ще добави стойност, а не ще създаде нови проблеми.
Фигура 4:Избор на задачи за поддръжка
Избраните от нас задачи са описани по следния начин:
Проверка на целостта на базата данни task извършва вътрешни проверки за последователност на данните и индексните страници в базата данни.
Индексът за реорганизиране задачата дефрагментира и уплътнява клъстерирани и неклъстерирани индекси на таблици и изгледи. Това ще подобри производителността при сканиране на индекси.
Индексът за възстановяване task реорганизира данните за данните и индексните страници чрез преизграждане на индекси. Това подобрява производителността на индексните сканирания и търсения. Тази задача също така оптимизира разпределението на данни и свободното пространство на индексните страници, което позволява по-бърз бъдещ растеж.
Актуализиране на статистиката задача гарантира, че оптимизаторът на заявки разполага с актуална информация за разпределението на стойностите на данните в таблиците. Това позволява на оптимизатора да прави по-добри преценки относно стратегиите за достъп до данни.
Почистване на историята задачата изтрива исторически данни за операциите по архивиране и възстановяване, агент на SQL Server и план за поддръжка. Този съветник ви позволява да посочите типа и възрастта на данните, които да бъдат изтрити.
База данни за архивиране (пълна) task ви позволява да посочите изходните бази данни, дестинационни файлове или ленти и опции за презаписване за пълно архивиране.
Почистване на поддръжка задачата премахва файловете, останали от изпълнението на план за поддръжка.
Фигура 5 показва къде избираме реда, в който се изпълняват тези задачи. Това е важно поради няколко причини. Например, няма смисъл да се извършва актуализация на статистиката на индекса след възстановяване на индекс, тъй като повторното изграждане на индекс също извършва актуализиране на статистически данни на индекса в SQL Server. Ще видим по-нататък в статията как ще се справим с това предвид избрания от нас ред. Друго възможно съображение е, че може да решите, че е по-разумно първо да направите резервно копие, преди да продължите с определени видове поддръжка.
Фигура 5:Ред на задачите
На фигура 6 избираме към кои бази данни искаме да приложим първата задача за поддръжка. Това трябва да направим и за всяка от следващите задачи. Това е важно в смисъл, че някои бази данни може да се наложи да бъдат освободени от такива операции. Например, когато имате комбинация от много големи бази данни (VLDB) и много малки бази данни в същия екземпляр (сама лоша идея), може да се наложи да изключите VLDB от напълно сляпо възстановяване на индекса. В такъв случай трябва да идентифицирате ключовите таблици в тази VLDB и да съсредоточите повторното изграждане и други операции по интензивна поддръжка върху ключови таблици. В този пример съм изключил системните бази данни, тъй като мога внимателно да планирам поддръжката за тях отделно. Смятам, че е по-безопасно да се борави с системните бази данни отделно, като се има предвид, че всяка повреда върху тях може да повлияе на целия екземпляр.
Фигура 6:Определете обхвата
Всяка операция по поддръжката има свой собствен набор от опции. Фигура 7 показва опциите, които трябва да вземем за DBCC CHECKDB. Отклоних се леко от настройките по подразбиране, като увеличих MAXDOP на 2. На фигура 8 избираме да изпълняваме тази задача в 1:00 часа сутринта в събота и неделя вечер.
Фигура 7:Опции за DBCC
Фигура 8:DBCC график
Задачата Reorganize Index също има специфичен набор от опции. Заслужава да се спомене наборът от условия, които ще определят дали даден индекс трябва да бъде реорганизиран или не – 30% фрагментация, 1000+ броя страници и последно използван най-много 28 дни отново. Този прозорец подчертава необходимостта от разбиране на опциите, които правим. За да направите тези опции правилно, трябва да разбирате индексите и индексирането в разумна степен. Имайте предвид, че подобни избори ще трябва да бъдат направени в задачата за възстановяване на индекса. Също така имайте предвид, че препоръчителният праг на фрагментиране за реорганизация на индекса всъщност е 15%, а не 30%.
Фигура 9:Опции за реорганизиране на индекса
Задачата за възстановяване на индекса предлага няколко други опции, освен тези за реорганизация на индекса. (Вижте Фигура 10). Забележете, че избрах да сортирам резултатите в TempDB. За да бъде този избор ефективен, важно е да настроите TempDB по подходящ начин, тъй като изборът предполага, че сортирането за тази операция във ВСИЧКИ бази данни ще се случи в TempDB. Освен това трябва да настроим графика за възстановяване на индекса. Също така съм задал MAXDOP на 2 за тази задача.
Фигура 10:Опции за възстановяване на индекса
Споменахме по-рано, че когато се извика възстановяване на индекс в SQL Server, актуализацията на статистиката на индексите също се извиква по подразбиране. Така че, когато конфигурираме задачата за актуализиране на статистиката, избираме да актуализираме само статистически данни за колони (Фигура 11). Този прозорец също ни дава възможност да направим пълно сканиране или да вземем проби. Тъй като контекстът е малки бази данни, ние избираме опцията за пълно сканиране. Отново, това изисква известно разбиране на статистиката.
Фигура 11:Задача за актуализиране на статистиката
Избираме да конфигурираме задачата за почистване, за да изтрием всички данни, по-стари от 4 седмици, както е показано на Фигура 12.
Фигура 12:Задача за почистване на историята
Задачата за архивиране разкрива доста множество опции за конфигурация в три раздела! Фигура 13 показва, че избираме да ограничим тази задача за архивиране до потребителски бази данни. Планираме го за 3:00 сутринта в неделя и отиваме по-далеч, за да изберем дестинацията за архивиране като E:\MSSQL\Backup (вижте фигура 14). В третия раздел (Фигура 15) правим избор за проверка на архива и също така извършваме контролна сума, така че сме по-близо до това да сме сигурни, че архивът е надежден.
Фигура 13:Задача за архивиране на база данни
Фигура 14:Дестинация за архивиране
Фигура 15:Опции за архивиране
Накрая конфигурираме задача, която ще управлява запазването на нашия дневник на плана за поддръжка. (Фигура 16). Отново избираме да изтрием всички регистрационни записи, по-стари от 4 седмици. Фигура 17 показва опциите, които избираме, за да гарантираме, че дейностите на плана за поддръжка са регистрирани, както и изпратени по пощата до групата на администратора на базата данни. Разбира се, за да работи тази последна опция, трябва да сме конфигурирали Database Mail и да сме настроили правилно операторите.
Фигура 16:Задача за почистване на плана за поддръжка
Фигура 17:Опции за отчет
Фигури 18 и 19 показват обобщение на задачите, които сме конфигурирали, и обратна връзка за успешното завършване на съветника.
Фигура 18:Резюме на опциите
Фигура 19:Завършване на съветника
План за поддръжка за ежедневни задачи
Можем също да създадем отделни планове за поддръжка за други цели, като например просто организиране. Не е необходимо да създаваме отделен план за ежедневните задачи, тъй като можем да конфигурираме графиците отделно за всяка задача. Една от причините, поради които може да искаме да създадем отделен план, може да бъде да изберем различен набор от задачи, насочени към различен набор от бази данни (всъщност, все още може да можем да направим това и в съществуващия план).
В следващия пример нека приемем, че имаме друг набор от големи бази данни в рамките на същия екземпляр с различни цели на точката на възстановяване. След това трябва да използваме различна стратегия за архивиране – ежедневен график за диференциално архивиране и почасов график за архивиране на регистрационния файл на транзакции в допълнение към седмично пълно архивиране, за да осигурим RPO от 1 час. (Вижте фигури 21 и 22).
Фигура 20:Ежедневен план за поддръжка на задачи
Фигура 21:Диференциални и Tlog задачи за архивиране
Фигура 22:Задача за план за ежедневна поддръжка
За диференциалното архивиране ние избираме дневен график, който се задейства в 2:00 сутринта всеки ден. (Вижте Фигура 23). И изберете същите опции за архивиране, както направихме за пълното седмично архивиране, конфигурирано по-рано.
Фигура 23:План за ежедневна поддръжка
Фигура 24:Диференциално местоположение за архивиране
Фигура 25:Диференциални опции за архивиране
От друга страна, ние избираме да планираме диференциалното архивиране да се извършва всеки час от всеки ден. Ние също така гарантираме, че всеки набор за архивиране на база данни се съхранява в директория със собствено име. Останалата част от съветника е почти същата като предишното ръководство.
Фигура 26:График за архивиране на регистрационния файл на транзакциите
Фигура 27:Местоположение за архивиране на регистрационния файл на транзакциите
Фигура 28:Опции за архивиране на регистрационния файл на транзакциите
Заключение
След завършване на съветника за план за поддръжка, ние получаваме план за поддръжка и съответен набор от задачи за SQL агент (вижте фигура 29). По същество планът за поддръжка е колекция от пакети SSIS и когато прегледате планираните задачи, ще откриете, че стъпката на заданието, изпълнена във всяка задача на подплан, е пакет SSIS (вижте фигура 30).
В следващ пример ще покажем, че можем да изпълняваме заданията на подплана годишно. Ние също така ще прегледаме резултатите от изпълнението на плана за поддръжка и ще отстраним грешки, свързани с изпълнението на стъпките на заданието. Ще разгледаме и дневника на плана за поддръжка.
Фигура 29:Получени задачи за SQL агент
Фигура 30:Стъпка на заданието на пакета SSIS
