Кубовете изискват често наблюдение, тъй като производителността им намалява доста често (забавяне по време на изграждане на заявка, увеличаване на времето за обработка). За да разберем причината за намаляването, трябва да наблюдаваме нашата система. За това използваме SQL Server Profiler. Въпреки това, Microsoft планира да изключи този инструмент за проследяване на SQL в следващите версии. Основният недостатък на инструмента е интензивността на ресурсите и трябва да се изпълнява внимателно на производствен сървър, тъй като може да причини критична загуба на производителност на системата.
По този начин Extended Events е обща система за обработка на събития за сървърни системи. Тази система поддържа корелация на данни от SQL Server, което позволява получаване на събития за състоянието на SQL Server.
Архитектурата на системата е показана по-долу:
Всъщност имаме пакет, който съдържа събития, цели, действия, типове, предикати и карти. На сървъра се изпълняват сесии, съдържащи събития, цели, действия. Няма да описвам подробно архитектурата, тъй като помощта съдържа изрично описание.
Сега да се върнем към нашия SSAS. За да направим всичко по-ярко, нека разгледаме няколко сценария, които използваме за анализ на проблемите.
Първи сценарий:Анализ на обработка на куб (Многомерен куб)
Често се случва, когато кубът се актуализира за много дълго време по време на обработка, въпреки че обемът на данните е доста малък. За да разберем причината, трябва да разберем каква заявка или кое място на обработка причинява забавянето. Разбира се, можем да пуснем обработка в Production и да видим какво се случва, но не съм сигурен, че потребителите ви ще оценят това. Тук на помощ идва Extended Events. Нека стартираме нашата сесия и конфигурираме нейното запазване във файл.
Да отворим SSMS и да се свържем със SSAS, след което да преминем към Управление.
Сега нека създадем нова сесия:
- В раздела Общи посочете име за нашата сесия и заредете шаблон.
- Събитията Разделът показва събитията, които ще ни помогнат да анализираме проблемите. Разделът включва всички наши стари приятели от Profiler. Нека изберем следните събития за обработка на анализ:CommandBegin , CommandEnd, Програм essReportBegin и ProgressReportEnd, ResourseUsage.
CommandBegin , CommandEnd ще покаже началото и края на изпълнението на командата по време на обработка.
Програм essReportBegin и ProgressReportEn предоставят разширена информация за дължината на всяко събитие и показват прочетени данни, изпълнение на SQL заявки, дължина и т.н.
Използване на ресурси показва броя на ресурсите, изразходвани за изпълнение на заявка, действие.
Когато изберем събитията, можем да преминем към конфигуриране на всяко събитие и да посочим кои събития трябва да се показват и кои да бъдат скрити (например можем да скрием идентификатора на процеса).
- Съхранение на данни раздел. Тук можем да посочим или да показваме събития в режим на реално време, или да ги запишем във файл:
- файл_събитие – запис на събитие във файл за по-нататъшен анализ. Посочете максималния размер на файла и пътя към местоназначението. Ако размерът на файла надвишава посочения размер, ще бъде създаден нов файл. Също така можем да посочим броя на файловете, които трябва да бъдат създадени (максимален брой файлове).
- поток_събитие – позволява гледане на събития в режим на реално време.
- ring_buffer – указва, че данните за сесията трябва да се съхраняват в паметта, докато сървърът работи. В случай на презареждане данните ще бъдат премахнати.
- Разширени Разделът позволява конфигуриране на ресурси (памет, процесор) за дадена сесия.
Накрая щракнете върху OK и вземете сесията. Нека стартираме обработката на куб и да видим обработката по събития. Превключете към режим на данни на живо.
В горната част на следващата екранна снимка можем да видим събитията, които се случват в момента с нашия екземпляр. Подробности за събитията са показани в долната част. Всяка стойност на подробностите за събитието може да бъде добавена като отделна колона в горната част. Щракнете с десния бутон върху избрана стойност от подробностите за събитието и ги прегледайте в таблица.
В резултат получаваме следния изглед:
Следователно разширените събития позволяват да анализираме нашата обработка в режим на реално време. Можем да разберем колко време е изразходвано за обработката на всеки обект, колко ресурси се използват при това. Това помага да се направят заключения и да се намерят слаби места. Освен това не претоварваме системата и не получаваме загуба на производителност.
Можете също да създадете сесия чрез XMLA. Можете да извлечете скрипта в GitHub.
Спирането и изтриването на сесия е възможно както чрез SSMS, така и чрез XMLA.
- Чрез SSMS (въпреки това през 2016 г. възниква грешката и не успях да изтрия сесията чрез интерфейс).
- XMLA скрипт – може да бъде изтеглен тук.
Това е първата част от статията за разширени събития за SSAS. Във втората част ще разгледаме сценарий на анализ на производителността на заявките в куб, работа с файл за проследяване и анализиране на файла чрез Power BI.
Препоръчвам също да разгледате следните публикации в блога:
- Pinal Dave – SQL SERVER – SQL Profiler срещу разширени събития
- Chris Web — Профилинг, разширени събития и услуги за анализ. Въпреки че авторът на статията заявява, че Profiler почти не се използва на производствени сървъри, но потвърждава проблемите му с натоварването на сървъра.
- Брент Озар — Разширени събития на SQL Server
