Като DBA адресирането на проблеми с производителността често е реактивно събитие; възникне проблем, трябва да отговорите. Понякога разглеждате екземпляр на SQL Server, който познавате добре, друг път може да е първата ви среща със среда. Това се случва и в света на консултациите. Когато помагам на дългосрочен клиент, вече имам записани подробности за средата. Въпреки това, когато получим имейл от някой, с когото не сме работили преди, и това е спешна ситуация, при която те искат незабавна помощ, ние нямаме информация за околната среда и нямаме представа в какво се намираме. Ние предоставяме помощ, без да преминаваме през обширния процес на събиране и анализ на данни, който започва всеки нов клиент.
Поради тази причина имам набор от пет елемента, които проверявам веднага, когато се сблъскам с нова среда. Информацията, която събирам, поставя основата за начина, по който подхождам към отстраняването на неизправности занапред и макар че рядко посочва ТО конкретен проблем, това ми помага да изключа кое е НЕ проблема, който понякога е също толкова важен.
Методи за събиране на данни
Признавам, че всеки има различен подход, когато се справя с нова среда. Има няколко безплатни, широкодостъпни скрипта, които можете да изтеглите и стартирате, за да ви дадат „обзора на земята“ за екземпляр на SQL Server (спомня се за DMV скриптовете на Glenn Berry). Фокусът тук не е как вие събирате данните, това е какво данни, които събирате, и това, което анализирате първо .
Свойства на сървъра
Първото нещо, което искам да знам, когато гледам екземпляр, е версията и изданието на SQL Server. Най-бързият начин да получите тази информация е да изпълните:
SELECT @@VERSION;
С този изход мога да проверя компилацията, за да определя приложените сервизни пакети, кумулативни актуализации и спешни корекции и знам кое издание се използва. Също така ми харесва да знам дали екземплярът е клъстериран, така че изпълнявам и:
SELECT SERVERPROPERTY('IsClustered'); Понякога имам тази информация от клиента, но никога не пречи да потвърдя, тъй като версията и изданието могат да повлияят на следващите стъпки и препоръки за отстраняване на неизправности. Например, наскоро клиент се свърза с нас относно периодичен проблем с производителността, който видя с SQL Server 2008. Бърза проверка на версията разкри, че те работят със SQL Server 2008 SP3 и имаше няколко Кумулативни актуализации, пуснати след SP3, които адресираха редица проблеми с производителността. Въпреки че събрах повече информация, преди да дам препоръка да прилагат най-новия CU, това беше незабавно червен сигнал за това какво може да причинява проблема.
sys.configurations
Този изглед на каталог помага да надградим основата, започната със свойства на сървъра, и ни помага да разберем как е конфигуриран екземплярът. С този изглед търся настройки, които са били променени от стойностите по подразбиране, но не е трябвало да бъдат, и тези, които не е променено, но трябва.
SELECT [name], [value], [value_in_use], [description] FROM [sys].[configurations] ORDER BY [name];
Помислете за настройката за максимална памет на сървъра (MB), която ограничава количеството налична памет за буферния пул. Стойността по подразбиране е 2147483647, но трябва да бъде променена на стойност, по-малка от общата памет на сървъра, за да се гарантира, че има достатъчно памет за операционната система, други приложения и други задачи на SQL Server, които изискват памет, която не се взема от буферния пул . За насоки относно задаване на подходящата стойност за максимална памет на сървъра (MB), препоръчвам публикацията на Джонатан „Колко памет всъщност се нуждае от моя SQL Server?
Обратно, настройката за приоритетно усилване има по подразбиране нула и винаги трябва да се оставя като такава. Всъщност Microsoft препоръчва да не го променяте и опцията ще бъде премахната в бъдеща версия на SQL Server.
sys.databases
След като разбера как е конфигуриран екземплярът, след това гледам какво съществува на ниво база данни.
SELECT * FROM [sys].[databases] ORDER BY [database_id];
Когато проверявам изхода на този изглед на каталог, търся анти-модели – всичко, което изскача като неочаквано или нетипично – в данните. Резултатът е благоприятен за бърз анализ – много от настройките изброяват 0 или 1 за стойността (изключено или включено) и аз отбелязвам наум какво е различно. Очаквам автоматичното създаване на статистики и статистическите данни за автоматично актуализиране да бъдат активирани (настроени на 1). Очаквам автоматичното затваряне и автоматичното свиване да бъдат деактивирани (настроени на 0). Гледам да видя какво е съпоставянето за потребителските бази данни, по-конкретно дали всички те имат еднакво съпоставяне и дали това съпоставяне е същото като tempdb. Също така отбелязвам опции за сигурност като свързване на кръстосани бази данни и опцията is_trustworthy, като и двете са деактивирани (0) по подразбиране. Ако установя, че някоя от тези настройки се отклонява от това, което очаквам, отбелязвам го и продължавам напред. В нито един момент не спирам събирането или анализа си, за да направя промяна, тъй като просто събирам информация възможно най-бързо, за да разбера добре средата.
В допълнение към проверката на настройките за базите данни, аз също вземам под внимание броя на потребителските бази данни. Няма „правилен брой“ потребителски бази данни за даден екземпляр – екземплярът може да работи лошо с една база данни и може да работи чудесно със 100. В играта има безброй фактори, а броят на базите данни е просто точка от данни заслужава да се отбележи.
Регистъри за грешки
Признавам, пренебрегвах ERRORLOG на SQL Server; беше като мисъл след това, когато разследвах проблем със SQL Server. Тогава осъзнах грешката на моите пътища и оттогава не го приемам за даденост. Склонен съм да навигирам през Management Studio за достъп до дневника (в рамките на Management | SQL Server Logs), въпреки че можете да използвате съхранената процедура sp_readerrorlog или да прегледате файла и да го отворите любимия си текстов редактор.
В рамките на ERRORLOG търся скорошни грешки – например всичко, свързано с паметта – и също гледам какви флагове за проследяване, ако има такива, се използват. Също така проверявам дали заключването на страници в паметта е активирано, дали кешът се промива (нарочно или не) и дали някаква друга необичайна дейност се случва редовно. В зависимост от това колко спешен е проблемът, разглеждам и регистрационните файлове на Windows (събития, приложения и сигурност), отново не просто търся грешки, но и неочаквани модели на съобщения.
Изчакайте статистика
Последната област на SQL Server, която преглеждам, когато разглеждам проблем с производителността на неизвестен екземпляр, е статистиката за чакане. Всеки екземпляр на SQL Server ще има изчакване – без значение колко добре е настроен кодът, без значение колко хардуер стои зад него. Като DBA, вие искате да знаете какви са вашите типични изчаквания за пример и когато разглеждам нова среда, не знам веднага дали чаканията, които виждам, са типични или се дължат на проблем с производителността. Питам клиента дали имат базови статистически данни за изчакване и ако не, питам дали мога да ги изчистя и да ги оставя да започнат да се натрупват, докато възникне проблемът с производителността. За да проверите статистиката за чакане, можете да използвате скрипта в често споменаваната публикация на Пол Рандал или версията в DMV заявките на Глен.
След като прегледате натрупаната статистика за чакане, ще имате последната част, която предоставя „голямата картина“ на екземпляра на SQL Server и информацията, от която се нуждаете, за да започнете да отстранявате неизправности. Не е необичайно първо да проверите статистиката за изчакване при отстраняване на неизправности, но само изчакването не е достатъчно информация, за да определите какво трябва да проучите по-нататък, освен ако не разбирате и основната конфигурация на SQL Server.
Следващи стъпки
Както споменах по-рано, обикновено няма нито една част от данни, която да ви каже къде се крие проблемът с производителността, това са множество точки от данни, получени, които ви насочват в правилната посока. Как да хванете тази информация зависи от вас, но след като прегледате изхода, трябва да имате добро разбиране за това как е конфигурирана средата на SQL Server и това знание, комбинирано със статистиката за чакане, може да ви помогне да решите какво да проучите по-нататък. Отстраняването на неизправности работи най-добре с методичен подход, така че започнете с основите и работете, а когато смятате, че сте определили основната причина, копайте още малко и намерете едно или две допълнителни доказателства, които подкрепят вашето откритие. След като разполагате с тези данни, можете да направите препоръка за подобряване или разрешаване на проблема.
