Преподавам и пиша за често срещани грешки в SQL Server от много години. Написах и блог за това преди години, но с течение на времето насоките се промениха малко. Тази статия ще разшири предишната ми статия и ще посочи как те се отнасят за SQL Server, Azure SQL база данни и Azure SQL управляван екземпляр.
В продължение на много години откривам потребители, които правят едни и същи грешки. Наричам ги грешки обаче, в повечето случаи по-скоро нещата не се правят както трябва, защото хората, управляващи околната среда, не знаят нищо по-добре. Ето някои от по-критичните елементи, за които всеки, който инсталира и поддържа SQL Server, трябва да знае:
- Архивиране
- DBCC CHECKDB
- Настройки на паметта
- Статистика
- Поддръжка на индекса
- MAXDOP и праг на разходите за паралелизъм
- Сигнали за агент на SQL Server
Резервни копия
Винаги първо проверявам резервните копия, когато разглеждам нова система. Наличието на подходящи архиви за постигане на целите за възстановяване е от решаващо значение. Загубата на данни може да бъде пагубна за организацията. Когато разглеждам архиви, проверявам за модел на възстановяване и текущата история на архивите за всяка база данни. Обикновено намирам комбинация от следното:
- Изобщо без архивиране – няма запис за архивиране на базата данни
- Липсващи архиви – няма архивиране на регистрационни файлове за база данни, използвайки модела за пълно възстановяване
- Няма скорошни архиви – последното архивиране беше на седмици/месеци/години
Неправилно конфигурираните архиви са пагубни за организацията, когато възникне ситуация с възстановяване. Работата и да се налага да кажете на клиентите, че са загубили данни, никога не е забавно или лесно. Наличието на подходящи резервни копия за спазване на SLA трябва да бъде основен приоритет на всяка организация в допълнение към гарантирането, че има копия на тези резервни копия, съхранявани на вторично място извън сайта.
Тази ситуация се отнася за локалния SQL Server и IaaS. Azure SQL база данни и Azure Managed Instance имат управлявани архиви.
DBCC CHECKDB
За съжаление се случва корупция в базата данни. Без редовно да проверяват за корупция, клиентите могат да се окажат на лошо място, като нямат резервни копия, за да се възстановят, когато тази повреда засегне физическите данни. За да се провери за повреда, DBCC CHECKDB трябва да се изпълнява редовно срещу всяка база данни. Това, което намирам, е много подобно на архивирането:
- Изобщо не са извършени DBCC CHECKDB
- DBCC CHECKDB се извършва само на избрани бази данни
- DBCC CHECKDB са извършени последно преди месеци или години
В най-лошия случай е планирано задание да отчита неуспешни DBCC CHECKDB
Никога не е приятно да откриете корупция или да накарате клиент да се свърже с проблем с корупцията, когато корупцията е купчина или клъстериран индекс и няма резервни копия преди появата на корупцията. В тези случаи повредата е действителните данни и започването на възстановяването от преди повредата в повечето случаи е единствената възможност. В случаите, когато повредата е неклъстериран индекс, възстановяването на индекса е решението.
В няколко ситуации ми се е налагало да работя с клиенти, които имат неприятна корупция без подходящи резервни копия, където успях да скриптира базата данни и ръчно да копирам всички използваеми данни в новосъздадена база данни. Тези скъпоструващи ситуации могат лесно да бъдат избегнати чрез стартиране на DBCC CHECKDB и правилно запазване на резервно копие.
Съветвам клиентите да стартират DBCC CHECKDB на място, IaaS, Azure SQL база данни и Azure SQL управляван екземпляр. Azure върши чудесна работа с проверката за физическа повреда; обаче смятам, че потребителите трябва да проверяват за логическа корупция.
Настройки на паметта
Инсталацията по подразбиране на Microsoft SQL Server има минимална стойност на паметта, зададена на 0, и максимална стойност на паметта на сървъра, зададена на 2147483647 MB, което е 2 петабайта. Преди SQL Server 2012 максималната стойност на паметта на сървъра се прилагаше само към буферния пул, така че клиентите трябваше да ограничат количеството памет, което буферният пул може да използва, за да пести памет за операционната система и други процеси. SQL Server 2012 въведе пренаписване на мениджър на памет, така че максималната стойност на паметта на сървъра да се прилага за всички разпределения на памет на SQL Server.
Силно препоръчително е да зададете максимална стойност за вашия екземпляр на SQL Server. Jonathan Kehayias написа публикация в блога Колко памет всъщност се нуждае от моя SQL Server, с формула, която помага да се установи базовата линия за максималната стойност на паметта. В случаите на споделен SQL сървър препоръчвам на моите клиенти да зададат минималната стойност на 30% от паметта на сървъра.
В ситуации с множество екземпляри или когато сървърът се използва за SQL Server, SSIS, SSAS или SSRS, трябва да прецените от колко памет се нуждаят тези други системи и да намалите максималната стойност на паметта на сървъра, за да позволите адекватна памет за ОС и другата услуги.
Този проблем е валиден за локални, IaaS и частично за Azure SQL управляван екземпляр. Управляваната инстанция задава максимална стойност на паметта на сървъра въз основа на внедреното ниво, но когато тествах преоразмеряването на средата, максималната стойност на паметта не се променя динамично. В тази ситуация ще трябва ръчно да актуализирате стойността. Този проблем не се отнася за Azure SQL база данни.
Статистика
Оптимизаторът на заявки използва статистически данни за изграждане на планове за изпълнение. Това означава, че SQL Server се нуждае от статистика, за да бъде актуална, така че оптимизаторът на заявки да има по-голям шанс да изгради добър план за изпълнение. По подразбиране статистическите данни се актуализират след промяна на 20% +500 реда данни. Това може да отнеме много време на по-големи маси. Започвайки с ниво на съвместимост 130, прагът за актуализации на статистиката за големи таблици е намален. За SQL Server 2008R – 2014 можете да намалите този праг, като използвате флаг за проследяване 2371.
Редовно установявам, че клиентите не актуализират ръчно статистическите данни и дори с по-ниския праг открих, че ръчното актуализиране прави средата по-стабилна.
Препоръчвам на клиентите да използват скрипт на трета страна за актуализиране на статистиката. Ola Hallengren публикува широко използвано решение за поддръжка за SQL Server. Част от този процес е неговата процедура за оптимизиране на индекса, която може да изисква допълнителни параметри за актуализиране на статистиката.
@UpdateStatistics
ALL = update index and column statistics
INDEX = update index statistics
COLUMNS = update column statistics
NULL = Do not perform statistics maintenance (this is the default)
@OnlyModifiedStatistics
Y = Update statistics only if rows have been modified since most recent stats update
N = Update statistics regardless of whether any rows have been modified
Открих, че клиентите, които използват продукти или скриптове на трети страни за извършване на поддръжка на индекса въз основа на нивото на фрагментация на индекса, не смятат, че реорганизациите не актуализират статистиката, както правят повторното изграждане. Много от тези приложения на трети страни имат опции за актуализиране на статистически данни, точно като процедурата за оптимизиране на индекса на Ola, просто трябва да я включите.
Актуализирането на статистическите данни се прилага за локални, IaaS, Azure SQL база данни и Azure SQL управляван екземпляр.
Поддръжка на индекса
Извършването на поддръжка на индекси чрез премахване на фрагментацията от вашите индекси все още е важно. В някои оттеглени документи от Microsoft се посочва, че фрагментирането на индекса може да има отрицателно въздействие от 13-460% в зависимост от размера на средата и нивото на фрагментация. Въпреки че хардуерът като интелигентни SAN, Solid State Disk и други подобрения помогнаха за ускоряване на нещата, загубеното място в индекса може да се превърне в загубено пространство в буферния пул, както и до загуба на повече I/O.
Фрагментирането се случва чрез редовни операции като вмъкване, актуализиране и изтриване. За да поправите това, е необходима правилна поддръжка на индекси за възстановяване или реорганизиране на вашите индекси. Отново се обръщам към Ола Халенгрен за неговия скрипт за оптимизиране на индекса. Скриптът на Ola предоставя възможността да посочите повторно изграждане или реорганизиране въз основа на нивото на фрагментация и минималните страници. Много инструменти на трети страни предлагат същата логика. Плановете за поддръжка на база данни на SQL Server преди SQL Server 2016 позволяваха само да се изградят или реорганизират всички индекси. Започвайки със SQL Server 2016, вече можете да посочите подобна логика въз основа на нивата на фрагментация. Не забравяйте обаче тези статистически данни, ако използвате интелигентна логика, базирана на нива на фрагментация.
Харесвам скрипта на Ola и инструментите на трети страни, които се регистрират в таблица. След това мога да направя заявка към таблицата, за да видя дали имам горещи точки в индекса, където фрагментацията се случва постоянно на високи нива, и да отстраня защо фрагментацията е толкова разпространена и може ли да се направи нещо.
Има изключения от всяко правило или най-добра практика. Някои модели на достъп до данни водят до постоянна фрагментация. Разходите за постоянно възстановяване/реорганизиране на тези таблици може да не си струват и могат да бъдат изключени от поддръжка. Тези ситуации трябва да се оценяват за всеки отделен случай.
Това се отнася за локални, IaaS, Azure SQL база данни и Azure SQL управляван екземпляр.
MAXDOP
Намирам, че максималната степен на паралелизъм и прагът на разходите за паралелизъм обикновено се оставят на стойностите по подразбиране на клиентските сървъри. За MAXDOP стойността по подразбиране е нула, което означава, че може да се използва „неограничен“ брой процесори за изпълнение на паралелен регион на заявка. Технически до 64 процесора, освен ако не активирате флаг за проследяване, за да използвате повече.
Преди десетилетие, когато процесорите имаха по-нисък брой ядра, тази стойност беше приемлива. Днес, с висока плътност на ядрото и сървъри с множество гнезда, неограничен брой процесори за паралелизъм не са толкова добри. Microsoft даде насоки какви стойности да се използват за MAXDOP.
Ако сте на SQL Server 2008 – SQL Server 2014, за един възел NUMA с по-малко от 8 логически процесора, запазете MAXDOP на или под броя на логическите процесори. Ако имате повече от 8 логически процесора, запазете MAXDOP на 8. Ако имате множество NUMA възли с по-малко от 8 логически процесора на NUMA възел, запазете MAXDOP на или под броя на логическите процесори на NUMA възел. По-голямо от 8, запазете MAXDOP на 8.
SQL Server 2016 въведе soft-NUMA възли. По време на стартиране на услугата, ако Database Engine открие повече от 8 физически ядра на NUMA възел или сокет, soft-NUMA възли се създават автоматично. Двигателят се грижи за поставянето на логически процесори от едно и също физическо ядро в различни soft-NUMA възли. Поради тази причина имаме малко по-различни указания за MAXDOP за SQL Server 2016 нататък.
Ако използвате SQL Server 2016 и по-нова версия, за един възел NUMA с по-малко от 16 логически процесора, запазете MAXDOP на или под броя на логическите процесори. Ако имате повече от 16 логически процесора, запазете MAXDOP на 16. Ако имате множество NUMA възли с по-малко от 16 логически процесора на NUMA възел, запазете MAXDOP на или под броя на логическите процесори на NUMA възел. По-голямо от 16, запазете MAXDOP на половината от броя на логическите процесори на NUMA възел с MAX стойност от 16.
Ако сте предимно виртуализирани на машини с 8 или по-малко логически процесора с MAXDOP по подразбиране, вероятно сте добре. Ако имате голям физически хардуер с настройки по подразбиране, тогава трябва да погледнете оптимизирането на MAXDOP.
Всички фигури по-горе са насоки, а не твърди истини. Работните ви натоварвания варират и трябва да се вземе предвид, когато определяте коя стойност е най-оптимална за вашето работно натоварване.
Конфигурирането на MAXDOP се прилага за локални, IaaS и Azure SQL управляван екземпляр. Въпреки това има конфигурация с обхват на база данни, която може да се приложи за всяка база данни, започвайки от SQL Server 2016, и това се отнася за Azure SQL база данни.
Праг на разходите за паралелизъм
Прагът на разходите за паралелизъм има стойност по подразбиране от 5. Историята на това число се връща към ранните дни на SQL Server и работната станция, на която е извършено тестване на работното натоварване. При съвременния хардуер оценката на разходите от 5 е остаряла. Тестването показа, че увеличаването на числото от 5 до по-висока стойност ще попречи на по-кратко изпълняваните заявки да имат паралелен план. Склонен съм да препоръчам увеличаване на тази стойност до по-високо число след преглед на кеша на плана. В много случаи започвам със стойност от 25 и след това следя допълнително и коригирам от там, ако е необходимо. За повече информация относно настройката на прага на разходите за паралелизъм, Джонатан Кехайяс написа:Настройка „праг на разходите за паралелизъм“ от кеша на плана.
Това се отнася за локални, IaaS и Azure SQL управляван екземпляр.
Сигнали за агент на SQL сървър
Всеки трябва да използва сигналите на SQL Agent, освен ако няма мониторинг на приложения на трета страна за същите условия на грешка. Конфигурирането на сигнали е лесно и безплатно, а конфигурирането им ще ви даде важна информация, когато сървърите ви имат проблеми.
Написах статия, озаглавена SQL Server Agent Alerts, предоставяща инструкции стъпка по стъпка как да създавате сигнали за грешки 19-25 и грешка 825. Активирането на тези сигнали е лесно:активирайте пощата на базата данни, създайте пощенски оператор и след това създайте сигнали. Това може да се постигне с помощта на GUI или с T-SQL. Насърчавам всички да напишат този процес с помощта на T-SQL и да го направят част от стандартната ви сървърна версия.
Това се отнася за локални, IaaS и Azure SQL управляван екземпляр.
Резюме
Както можете да видите, има много настройки, които трябва да бъдат променени от стойностите по подразбиране след инсталиране на SQL Server. Това не е изчерпателен списък; той обаче обхваща много от по-критичните проблеми и проблеми, които влияят на производителността, които намирам, и които съм поставил в категорията си „Неизправности в SQL Server“.
