Опасен ли SQL profiler?

[Naves]

Ну вы бы хоть пару тестов сделали бы для приличия, со всеми галочками и только с нужными. А то ведь те, кому нельзя запускать, и показать нужную статью с доказательствами не могут.

[Tzimie]

Это очень зависит от количества запросов, от того, насколько они легкие — много коротких или мало длинных, или

Мое правило, SQL:BatchCompleted и RPC:Completed с фильтром Duration>100ms точно безопасен.

[Mantikor]

Подскажите, пожалуйста, как безопасно в нем отследить что блокирует выполнение процедуры вплоть до ее завершения по таймауту?

[Tzimie]

Либо ловить event lock graph
Либо косвенно по тому что Duration >> того что можно ожидать из чисел CPU, Reads, Writes

[kolu4iy]

Кстати, у нас была ситуация, когда пошаговая отладка процедура роняла сервер. Ещё на 2008 сервере. На 2012 не пробовали ) зато у 2012 частенько врёт actual execution plan (некорректно показывает проценты у отдельных запросов в процедуре), и без профайлера с включенным sp:Statement completed реально не обойтись...

[epee]

зато у 2012 частенько врёт actual execution plan (некорректно показывает проценты у отдельных запросов в процедуре), и без профайлера с включенным sp:Statement completed реально не обойтись...

вполне даже обойтись

set statistics time on 

наше все, ну и туда же

set statistics io on 

правда статистика io может не все показать — например траблшутил запрос, вроде и план плюс минус нормальный, IO по таблицам низкий
но при этом statistics time показывает высокую нагрузку на CPU и высокий duration и это при том что по плану видно что ни хэширования ни сортировки нету, откуда ж такая нагрузка на CPU… ну и пристальнее взглянув увидел скалярную функцию в которой много всякого интресного происходило, а statistics io этого не показывала :(

[eefadeev]

Напомнило анекдот:
Поспорили терапевт с ветеринаром у кого работа сложнее. Спорили-спорили, не могут договориться. Ветеринар предлагает:
— Давай тестовый приём проведём?
— Давай!
— Ну вот представь, я пришёл к тебе на приём. Что бы будешь делать?
— На что жалуетесь?
— Э, нет! Так каждый дурак может!

[qw1]

Без проблем.
— Вот вам таблетка. Если не поможет, завтра усыпим.

[eefadeev]

Это, я так понимаю (если вернутся к ситуации в статье), приметно так:
— Накатите вот это патч. Если не поможет — грохните прод, он всё равно не работал.

[osipov_dv]

Есть разница, запускать профайлер через GUI или запустить Server Side Trace скриптом. На более свежих версиях предлагают забить на профайлер и использовать Extended Events.

[epee]

это предлагают почти с самого появления Extended Events, но они не так удобны и сложнее правильно настроить. в последних версиях SSMS появился «Extended Events Profiler», запускается по сути Extended Events сессия, но в обертке GUI привычного всем профайлера. правда количество ивентов которые можно через него отлавливать сильно ограничено, но наиболее нужное RPC Completed, Batch Completed и иже с ними конечно же присутствуют

[Brodyagos]

У нас около 1 000 000 запросов в час, немного, но пару раз запускали с настройками "как есть" что бы найти запросы от предыдущих талантов. Сервер не падал, нагрузка росла, но не критично

[Tzimie]

Да, пока нагрузка далека от 100% разумные трейсы лишь увеличивают CPU, не просаживая саму производительность

[Brodyagos]

Все должно быть в приделах разумного. У нас кстати был удивительный случай — монитор активности и запрос с записью во временную таблицу 200 000 записей наглухо вешали сервер вообще по памяти и цп, приходилось рубить на уровне виртуализации

[AlaXiZ]

У нас в компании используют несколько профилей, для выявления разных проблем: дедлоки, долгие запросы. Переходим сейчас на extended events, эту технологию рекомендует MS, поскольку сам профайлер deprecated. Плюсы EE более гибкая система получения информации о работе приложения, меньше проседает производительность по сравнению с профайлером, соответственно с меньшим риском можно запустить на проде

[Tzimie]

Это да
Но вот это

рекомендует MS, поскольку сам профайлер deprecated. Плюсы EE более гибкая система получения информации о работе приложения, меньше проседает производительность по сравнению с профайлером, соответственно с меньшим риском можно запустить на проде

достатточно, чтобы победить параною?

[epee]

ну опять таки, если внимательно посмотреть в настройки Extended Events сессии то для некоторых ивентов можно увидеть вот такое предостережение, например для события query_post_execution_showplan:
«Using this event can have a significant performance overhead so it should only be used when troubleshooting or monitoring specific problems for brief periods of time.»
поэтому хоть и eEvents и легче чем server side trace, тем не менее при неосторожном применении так же может стать причиной проседания производительности.
так что для параноии всегда будет место :)))

[epee]

я бы еще добавил что через eEvents можно отследить события которые в профайлере в принципе отсутствуют. например все (или почти все) события из канала Debug

[BalinTomsk]

---А как у вас обстоят дела?

периодически решаю проблемы у некоторых наших клиентов (самые большие компании в мире) и еще ни одна не отказала мне в просьбе запустить профайлер.

[jobgemws]

Лучше использовать расширенные события:
https://docs.microsoft.com/ru-ru/sql/tools/sql-server-profiler/sql-server-profiler?view=sql-server-ver15
В общем плане профайлер аффектит на производительность и если у вас система высоко нагруженная, то профайлером можно пользоваться только тогда, когда уже все раком встало (как ФГДС для исследования пищевода, желудка и 12-перстной кишки).
Также есть и другие сторонние инструменты для профилирования, такие как DBeaver и Event Profiler for SQL Server