„Докторе, притеснявам се за работата на моя SQL сървър.“
Това не беше нещото, което чувате от повечето пациенти. Но след това, като платен професионалист, бях обучен да се справям с всичко – дори и в трудните времена да бъда администратор на база данни.
"Наистина ли? Нека да проучим това, нали?"
„Разбира се, док. Искам да кажа, понякога се чувства толкова поразително. Мислех, че всичко ще се оправи от само себе си, след като се ангажирам. Но преди да се усетя, започнах да имам проблеми с производителността в SQL Server 2012, след това 2014, след това 2017. Дори не искам да мисля за SQL Server 2019."
"Виждам. Е, добрата връзка със SQL Server не се случва само по себе си. Трябва да работите върху това. Кажете ми, работили ли сте върху техниките за настройка на производителността на SQL Server?
„Ъъъ, не, док. Всъщност не познавам нито една от тези техники.”
„Не се тревожи. Можем да работим върху тях. Вашият SQL Server вероятно се чувства пренебрегнат. Трябва да го държите под око, за да сте сигурни, че сте по-напред от играта. Това изисква наблюдение на SQL Server.”
„Мониторинг? Как го правиш?"
„Трябва да покажете на SQL Server, че ви е грижа. Трябва да обърнете внимание на определени показатели. Можем да работим и върху това.”
„Добре, док. Каквото кажеш. Готов съм да опитам всичко в този момент. Нещата не биха могли да станат много по-лоши от сега.”
"Добре тогава. Нека да започнем."
Показатели за производителност на SQL Server — Много движещи се части
Пациентът беше прав:наблюдението на работата на вашия SQL Server може да се почувства непосилно. Не можете да спрете да му обръщате внимание, след като е стартиран и работи. Трябва да продължиш да му показваш, че ти пука.
SQL Server има много движещи се части, които постоянно генерират показатели. Да знаете кои да гледате и след това действително да отделите време от натоварения си ден, за да ги наблюдавате, може да бъде много работа за DBA.
Така че преминах през някои от основните области на показателите за производителност на SQL Server с пациента.
Индекси
Едно от първите места, които трябва да погледнете, когато имате проблеми с производителността на SQL Server, са индексите. Вашите данни винаги растат, така че вашите индекси също винаги растат. Но те са обект на условия като фрагментация и разделяне на страници, които могат да забавят отговора на заявките.
Какво се случва в база данни ден след ден? Потребителите създават, редактират и изтриват записи. Индексите са в крак с къде са всички части от записите, но с течение на времето фрагментацията на индекса пречи на производителността.
След това има коефициент на запълване на индекса, параметър, който можете да конфигурирате в SQL Server, за да контролирате броя на разделянето на страници и да увеличите ефективността на заявката. Но балансът между повече и по-малко разделяния на страници се отразява на производителността по други начини.
Гледане на показатели в коефициент на запълване , I/O ифрагментиране е добър начин да държите пръстите си върху пулса на здравето на индекса на SQL Server.
Буферен кеш
Нека направим това просто:Диск, бавен; буферен кеш, бърз. Буферният кеш е копие в паметта на наскоро използвани страници от база данни. Ако SQL Server не намери това, което търси там, той трябва да отиде на диск за него, което забавя производителността.
SQL Server ви позволява да зададете количеството системна памет, която да разпределите към буферния кеш, но вие обменяте паметта, останала за други задачи. Вашата цел е да разпределите колкото можете повече, без да възпрепятствате производителността на SQL Server в други области.
Също така важна е продължителността на живота на страницата, времето, през което страница с информация от базата данни прекарва в буфера, без да бъде достъпна отново. SQL Server непрекъснато изхвърля страници от буферния кеш, за да освободи място за по-скоро използвани такива. Но колкото по-малко полезни страници намира там, толкова повече трябва да чете от диск, което забавя производителността.
Показатели като продължителност на живота на страницата исъотношение на успешни посещения в буферния кеш ви помага да вземате решения за по-рядко изхвърляне на страници или увеличаване на размера на кеша.
T-SQL
SQL Server използва език за заявки, наречен T-SQL. Вместо да изпълнява SQL изрази ad hoc, SQL Server се опитва да подобри производителността, като ги пакетира, компилира ги като план за изпълнение и ги кешира. Той също така се опитва да сведе до минимум честотата на компилиране и повторно използване на планове за изпълнение възможно най-често. Ако не може да използва повторно плана за изпълнение - да речем, защото базата данни се е променила твърде много - тогава той ще прекомпилира плана. Най-добре е броят на повторното компилиране на SQL изрази да бъде възможно най-нисък, тъй като процесът може да изразходва големи количества CPU и да влоши производителността.
Необходимостта от компилиране и повторно компилиране е функция на добрите практики за кодиране, като използване на съхранени процедури и заявки за параметризиране. DBA, които наблюдават показатели като скоростта на SQL компилации и прекомпилации на SQL може да променя съветите за заявка на SQL Server, за да подобри производителността.
Заключване, изчакване и блокирани процеси
Разочароващо е да откриете, че някой друг променя нещо в същото време, когато вие. Така базите данни автоматично заключват неща като редове и таблици, за да не допускат множество готвачи извън кухнята. Компромисът за тази защита, разбира се, е, че всички останали потребители трябва да изчакат, докато ресурсът бъде отключен. И е трудно да се уверите, че заключването се извършва само на необходимото ниво.
С показатели, които показват колко често и колко широко заключванията засягат други операции, DBA могат да определят необходимостта от повече физически системни ресурси за обработка на транзакции по-бързо. Възможно е също така SQL Server да се заключва на ненужно ниско ниво. Честотата на изчакване на заключване и в по-общ план броят на блокираните процеси може да помогне за намиране на тесни места.
Елиминирайте тесните места с настройка на производителността на SQL
„Боже, докторе, прав си за всички движещи се части. Сега виждам как не мога просто да инсталирам SQL Server, да го настроя и да го забравя. Трябва да подхранвам връзката. Но всичко това все още се чувства поразително. Как изобщо ще поддържам толкова много различни неща и ще бъда напред в играта?”
„Това е най-добрата част. Има инструменти, които могат да помогнат за работата на вашия SQL Server. Не е нужно да го правите сами.”
„Уау! Това е успокояващо. Не знаех за това."
"Това е вярно. Инструментите наблюдават производителността на вашия SQL сървър и отчитат всички тези показатели, за да можете да приложите техниките си за настройка и да премахнете тесните места."
„Наистина?“
"Сигурен. И можем да работим върху тези правилни - о, боже, нямаме време за тази седмица. Моля, уговорете час с моя рецепционист и ние ще вземем другата седмица.”
„Момче, тези четири часа минаха бързо, докторе! Времето със сигурност лети, когато решавате проблеми с производителността около фрагментиране, използване на ресурси и съотношение на попадане в буферния кеш , нали?"
„Да, и съм сигурен, че след като общувате открито за тези проблеми с вашия SQL Server, всичките ви проблеми с производителността ще бъдат история.
Разочарован от нашата сесия, пациентът си тръгна. Следващия път ще работим върху наблюдението на тесните места в производителността на SQL Server. Ще пиша в блог за това, така че внимавайте.
Междувременно, повярвай ми. Аз съм платен професионалист и ви насърчавам да опитате тези неща във вашите собствени отношения с вашата база данни. Накарайте вашия SQL Server да се почувства желан. Обърнете внимание на показателите за ефективност.
Никога не е късно да опитате.
