Защо настройката на производителността на SQL е толкова важна за управлението на база данни?
Защото това може да ви спести много пари. Потърпете с мен и ще видите как.
Настройка на производителността на SQL и управление на база данни — свързване на точки
Повечето специалисти по база данни прекарват времето си в поддържане на светлините. Те инвестират по-голямата част от усилията си в осигуряване на време за работа, като следят ресурси като памет, съхранение и пропускателна способност на мрежата. Това е голяма част от управлението на бази данни, но тъй като все повече компании преместват своите бази данни към почти безгранични облачни ресурси като AWS и Azure, други аспекти стават все по-важни.
Настройката на производителността на SQL е един от тези аспекти. След като осветлението е безопасно включено и се придвижите нагоре по йерархията на нуждите в управлението на базата данни, следващото нещо, което искате, е по-добра производителност и това изисква настройка.
Първи въпроси, които трябва да зададете при настройка на производителността в SQL
Рано или късно много специалисти по бази данни се оказват пред SQL Server, който не са изградили. Няма много ръководства за тази ситуация. Настройката на производителността на SQL е упражнение за копаене, установяване какво не е наред и след това итеративно коригиране.
В първите си корекции може дори да не докосвате SQL изрази изобщо. Някои професионалисти в базата данни започват на ниво потребител/сесия. Те отиват там, където потребителите са недоволни, слушат как звучат оплакванията им и задават въпроси.
- Кои екрани или страници отнемат твърде много време за изобразяване?
- Приложението по-бавно ли е, когато създават нов билет или отварят съществуващ?
- Отнема ли много време за запазване на запис?
- Колко време е „дълго време?“
След като получат тези отговори, те отиват да видят какво в базата данни го причинява.
Това е по-добре, отколкото да седнете в първия ден и да решите да се справите с нещо като фрагментиране, което може изобщо да не засегне потребителите. Въпросът е да започнем с това, което интересува потребителите.
Помислете също и за нивото на екземпляр/база данни. В света на Microsoft, например, заетите за агент на SQL Server са добро място за начало. Те са поредица от действия, които обикновено определят административна задача, която можете да наблюдавате за успех или неуспех. Те са предназначени да бъдат удобни, но като много неща в управлението на бази данни, те са склонни да се натрупват, тъй като хората забравят как са възникнали и какво правят.
Може да откриете, че множество задачи изпълняват едно и също нещо, като например стартиране на различни версии на индексен скрипт или, още по-лошо, да работят една срещу друга. Разгледайте вече конфигурираните задачи в светлината на два въпроса:„Какво прави тази работа?“ и по-важното:„Ако спра тази работа, ще се случи ли нещо лошо?“
Кои фактори трябва да търсите?
След като стигнете до нивото на настройка на производителността на SQL, той взема своите сигнали за поведение от няколко фактора. Както е описано по време на нашето Уебкаст „Попитайте експертите:Кръгла маса за ефективността на базата данни“, можете да отделите по-малко време за настройка на самия SQL, ако откриете и интерпретирате правилно фактори като тези:
- Блокиране — Ако сървърът блокира, това е като бомба със закъснител. Да предположим, че скрипт стартира транзакция и не я затваря; това може да доведе до регистрационен файл, който просто расте и расте, докато мястото свърши. Блокирането е лоша новина за производителността, така че потърсете го веднага.
- Агенти — По отношение на задачите на SQL Server Agent, е известно, че администраторите неволно обвиват задачи, които влошават производителността, в работни места. Те могат да изпълняват транзакции или да изграждат отново индекси в задание или да свиват базата данни в транзакция. В такъв случай помислете за временно деактивиране на агента, за да изключите всички свързани задачи. Това е агресивна техника, но ако подобри производителността, ще разберете защо.
- Изчакайте статистика — Запитайте се:„Какво чака сървърът в момента?“ Показатели като продължителност на живота на страницата и дължина на дисковата опашка имат някои отговори, но предлагат само тесен изглед. Статистиката за изчакване ви показва всичко през обектива на видовете изчакване и категориите на чакане, като ви позволява да се съсредоточите върху петте или около тях чакащи събития, които отнемат най-много време. sp_BlitzFirst на Brent Ozar е надеждна съхранена процедура за откриване какво чакат вашите заявки към SQL Server в момента. След това, когато искате да изучавате дългосрочни модели в статистиката за изчакване за вашия сървър, потърсете инструмент за наблюдение на производителността.
- Администраторска дейност — Това е известно още като „пилотна грешка“, тъй като някои проблеми с производителността възникват от това, което правите сами. Да предположим, че изпълнявате едновременно SQL Server Activity Monitor и SQL Server Profiler , опитвайки се да научите Query Store. Не можете да изпреварите ефекта на наблюдателя; когато проследявате всичко по този начин, вие просто искате базата данни да се забави.
- Индекси — За нещо, което би трябвало да е полезно, индексите със сигурност могат да ви причинят болка във врата. Всъщност те заслужават повече от един куршум. Прочетете.
Настройката на производителността на SQL означава внимателно разглеждане на индексите
До голяма степен настройката на производителността на SQL се свежда до настройка на индекс. За щастие, ако овладеете това за локално управление на база данни, вашите умения могат лесно да се прехвърлят към управление на база данни в облака.
Настройката на индексите придобива все по-голямо значение поради развиващото се разнообразие от индекси: клъстерирани, неклъстерирани, уникални, филтрирани, columnstore, хеш, оптимизирани за памет неклъстерни, XML, пространствени и пълнотекстови, за да назовем само няколко. Но едно нещо, което никога не се е променяло, е първата колона на индекса, която управлява индексните решения, взети от механизма на базата данни.
Много доставчици продават и внедряват приложения с много добре предназначени индекси, които в крайна сметка никога не се използват или, още по-лошо, всъщност пречат на производителността. Ако разгледате неизползваните индексни скриптове или скриптове за потребление на индекси в някои софтуерни продукти, ще откриете изобилие от индекси на външен ключ. Ако продуктът използва, да речем, 20 външни ключа, доставчиците могат да доставят до 20 индекса, плюс десет индекса с една колона, плюс още десет индекса за уникален клъстериран индекс и т.н.
Винаги, когато имате възможност, по-добрият начин за подход към архитектурата на базата данни е да започнете с един клъстериран индекс, който смятате, че ще представлява най-добре таблицата. След това оставете системата да работи сама за известно време. Ако и когато имате нужда от повече индекси, създайте ги. Добавянето на индекси е упражнение за обмен на по-добра производителност тук с проблеми като запълване на дисково пространство и заключване там. Става трудно да се види как всеки допълнителен индекс влияе върху системата като цяло.
По този въпрос помислете за премахване на индекси - начина, по който човек с алергии би елиминирал групите храни - за да видите как се променя производителността. Опитайте се да махнете всеки индекс от вашия екземпляр за разработка и вижте кои от тях засягат петте ви най-добри заявки.
Настройка на производителността в SQL Server — инструменти, които идват с него
Имайте предвид, че не сте сами в това начинание. SQL Server включва функции, предназначени да подобрят производителността.
Ръководствата за планиране ви позволяват да промените начина, по който SQL Server изпълнява дадена заявка и въпреки че не е чиста настройка на производителността на SQL, това се отразява на производителността. Много приложения съдържат SQL заявки, написани от външен доставчик и дори тези заявки да причинят лоша производителност, някои специалисти по база данни разбираемо не са склонни да ги променят. С ръководствата за план можете да прикачите намек за заявка или фиксиран план към заявката и да повлияете на това как тя се изпълнява.
Недостатъкът на ръководствата за планиране обаче е, че въпреки че не се променят с времето, средата около тях го прави. Подобно на отпечатана пътна карта, те могат да работят добре в краткосрочен план и скоро да станат остарели, така че ако ще разчитате на тях, по-добре ги преглеждайте от време на време.
С ръководствата за планове е свързано Сохранението на заявки, функция на SQL Server, която ви помага да идентифицирате и настройвате заявките, консумиращи най-много ресурси във вашата система. Магазинът на заявки не е активиран по подразбиране за нови бази данни на SQL Server и Azure Synapse Analytics (SQL DW). Но той е активиран по подразбиране в новите Azure SQL бази данни.
Като цяло не е трудно да активирате Query Store, но не всеки SQL Server се нуждае от него от самото начало. Някои администратори не знаят за Query Store, а някои знаят за него, но все още не са отделили време да го проучат адекватно; по-добре е да го оставят деактивиран. По-късно, когато разберат как работи Query Store, те могат да го използват, за да намерят разликите в производителността, причинени от промените в плана на заявките.
И накрая, Database Engine Tuning Advisor анализира работните натоварвания и препоръчва индекси или стратегии за разделяне за подобряване на производителността на заявката. Пускането на Tuning Advisor във вашата база данни е добра идея; просто не го стартирайте твърде скоро. Уверете се, че вашата база данни съдържа достатъчно данни, така че препоръките за индекси да са валидни. Когато за първи път създавате приложението си, може да имате само хиляда реда във всяка таблица. Препоръките на Tuning Advisor са по-полезни, след като базата данни се разрасне.
Покажи ми парите
Както споменах в началото, настройката на производителността на SQL е важна за управлението на база данни, защото може да ви спести пари. Как?
Особено в облака, където мащабирането с кредитна карта е популярно, ИТ екипите откриват колко скъпо може да бъде месечното хранилище. Нещо повече, те започват да разбират, че изпълнението на лошо написани заявки и оставянето на AWS и Azure да управляват своите индекси увеличава разходите им за изчисления в облак. Бавните заявки и лошите индекси ви струват пари.
Настройката на производителността на SQL е да се оправят всички тези неща. По този начин, независимо дали оставате в света на локалните операционни разходи или мигрирате към света на CapEx на облака, вие поддържате контрол върху разходите си.
