Не знаю, как они выкручиваются для анализа проблем с производительностью, происходящей как раз в бизнес часы. Ведь performance views часто не дают точной картины, особенно если тормозит одна/две процедуры/квери, не нагружая особенно сам сервер. Крошечная кверь, выполняющаяся несколько раз в час и работающая 10 секунд вместо одной (но делающая очень важного клиента очень нервным) точно не попадет в DMV views. А select с CROSS APPLY по текстам кверей сам нагружает сервер очень нехило.
Однако мне интересно понять, откуда происходит эта боязнь. В некоторых фирмах SQL profiler – рабочий инструмент, в некоторых его боялись, как огня (какое то время я занимался консалтингом и мог сравнивать). Я почти уверен, что дело было так:
Хьюстон, у нас проблемы. Тормозит база. Разберись
Здесь столько галочек… Что же мне нужно?
Ладно, поставлю все галочки и потом решу.
Что остается в голове высокого начальства? Кто-то то запустил SQL profiler и все встало колом. И потом рассказывают это друг другу за партией в гольф.
Кстати, особую пикатность придает попытка записать такие ‘пишем все’ трейсы не в файл, а в базу на этом же сервере – один раз я был свидетелем такого случая.
А как у вас обстоят дела? Поучаствуйте в опросе пожалуйста
Комментарии (14)
kolu4iy
23.03.2019 23:31Кстати, у нас была ситуация, когда пошаговая отладка процедура роняла сервер. Ещё на 2008 сервере. На 2012 не пробовали ) зато у 2012 частенько врёт actual execution plan (некорректно показывает проценты у отдельных запросов в процедуре), и без профайлера с включенным sp:Statement completed реально не обойтись...
eefadeev
24.03.2019 00:45Напомнило анекдот:
Поспорили терапевт с ветеринаром у кого работа сложнее. Спорили-спорили, не могут договориться. Ветеринар предлагает:
— Давай тестовый приём проведём?
— Давай!
— Ну вот представь, я пришёл к тебе на приём. Что бы будешь делать?
— На что жалуетесь?
— Э, нет! Так каждый дурак может!
osipov_dv
24.03.2019 08:30Есть разница, запускать профайлер через GUI или запустить Server Side Trace скриптом. На более свежих версиях предлагают забить на профайлер и использовать Extended Events.
Brodyagos
24.03.2019 10:33У нас около 1 000 000 запросов в час, немного, но пару раз запускали с настройками "как есть" что бы найти запросы от предыдущих талантов. Сервер не падал, нагрузка росла, но не критично
Tzimie Автор
24.03.2019 17:30Да, пока нагрузка далека от 100% разумные трейсы лишь увеличивают CPU, не просаживая саму производительность
Brodyagos
24.03.2019 17:39Все должно быть в приделах разумного. У нас кстати был удивительный случай — монитор активности и запрос с записью во временную таблицу 200 000 записей наглухо вешали сервер вообще по памяти и цп, приходилось рубить на уровне виртуализации
AlaXiZ
24.03.2019 12:37У нас в компании используют несколько профилей, для выявления разных проблем: дедлоки, долгие запросы. Переходим сейчас на extended events, эту технологию рекомендует MS, поскольку сам профайлер deprecated. Плюсы EE более гибкая система получения информации о работе приложения, меньше проседает производительность по сравнению с профайлером, соответственно с меньшим риском можно запустить на проде
Tzimie Автор
24.03.2019 17:27Это да
Но вот это
рекомендует MS, поскольку сам профайлер deprecated. Плюсы EE более гибкая система получения информации о работе приложения, меньше проседает производительность по сравнению с профайлером, соответственно с меньшим риском можно запустить на проде
достатточно, чтобы победить параною?
Naves
Ну вы бы хоть пару тестов сделали бы для приличия, со всеми галочками и только с нужными. А то ведь те, кому нельзя запускать, и показать нужную статью с доказательствами не могут.
Tzimie Автор
Это очень зависит от количества запросов, от того, насколько они легкие — много коротких или мало длинных, или
Мое правило, SQL:BatchCompleted и RPC:Completed с фильтром Duration>100ms точно безопасен.
Mantikor
Подскажите, пожалуйста, как безопасно в нем отследить что блокирует выполнение процедуры вплоть до ее завершения по таймауту?
Tzimie Автор
Либо ловить event lock graph
Либо косвенно по тому что Duration >> того что можно ожидать из чисел CPU, Reads, Writes