Winnipuhlockyкстати, вы не поверите 99% профайлеров основаны как раз на стандартных процедурах.
И только этот профайлер основан на них на 80%.

ну , может быть не стоит прямо так... % посчитали...
обычно кастомные профайлеры используют sp_trace_xxx для создания трассы с записью в файл и fn_trace_xxx функции для чтения таблицы с трассой и визуализции оной. Некоторые профайлеры используют стандартную сборку (но смысла в этом особо нету, ибо если есть сборка - есть и нормальный профайлер)
Я использую только sp_trace_xxx процедуры.

Dmitry V. Liseevlockyкстати, вы не поверите 99% профайлеров основаны как раз на стандартных процедурах.
И только этот профайлер основан на них на 80%.Верю. Вот и рассказали бы на примерах, что такого дополнительного там есть по сравнению со стандартными возможностями. Тут народ уже деньги готовит за возможности существенного упрощения и ускорения отладки и профайлинга, а Вы стесняетесь рассказать об этом. А если тулза, как я тут намекнул, будет поддерживать возможность автоматизации обработки через командную строку/COM/PowerShell, так это уже серьезный коммерческий продукт будет.
1. Из возможностей - первое, что сразу бросается в глаза - можно взять экспресс, профайлер - и профайлить :)
Ну и плюс агрегация - описана в стартовом посте.
2. Коммерческий продукт? не вопрос. точнее - вопрос, философский. Стоит ли продавать приложение, написанное в качестве примера использования библиотеки?
3. А вот как раз библиотека - может быть использована в любом удобном режиме в составе кастомных приложений. О чем, собственно, написано по ссылке :)

SomewhereSomehowlocky1. Из возможностей - первое, что сразу бросается в глаза - можно взять экспресс, профайлер - и профайлить :)
Ну и плюс агрегация - описана в стартовом посте.
2. Коммерческий продукт? не вопрос. точнее - вопрос, философский. Стоит ли продавать приложение, написанное в качестве примера использования библиотеки?
3. А вот как раз библиотека - может быть использована в любом удобном режиме в составе кастомных приложений. О чем, собственно, написано по ссылке :)
Позволю себе высказаться на правах фокус группы (это в топике приветствуется, я так понял, да Winnipuh? =)) )
Основной недостаток стандартного профайлера, я вижу в том, что он сильно грузит сервер и не умеет нормально сохранять в таблицу. Соотв. если исправить эти недостатки - то будет круто. Например, профайлер открывает курсор для записи в таблицу, и отображает он-лайн. А можно было бы сделать чтобы профайлер писал все данные в файл, и сам опрашивал для визуализации этот файл, так же периодически заливал инфу с файла в таблицу, которую можно указать. Т.е. идея в том, чтобы взять лучшее от sp_trace и от профайлера, все это сделать так, чтобы нагрузка по мониторингу (ероме нагрузки от sp_trace) легла либо на клиента, либо на сервер и бд, который собирает данные мониторинга.
невозможно в принципе.
Либо сервер пишет трассу в файл - либо отдает тому или иному виду профайлера в виде рекордсета.
Для реализации иных принципов профайлинга нужно обращаться к разработчикам скуля.

SomewhereSomehowlockyневозможно в принципе.
Либо сервер пишет трассу в файл - либо отдает тому или иному виду профайлера в виде рекордсета.
Для реализации иных принципов профайлинга нужно обращаться к разработчикам скуля.
Возможно, может я неточно выразился. Возможно опрашивать файл. Возможно выводить в интерфейс результаты опроса.
тоже невозможно, без знания структуры файла. Копать которую - занятие то еще.
Можно, конечно, попробовать, на досуге.

SomewhereSomehowlockyтоже невозможно, без знания структуры файла. Копать которую - занятие то еще.
Можно, конечно, попробовать, на досуге. Зачем вам файл, МС предоставляет замечательную функцию fn_trace_gettable. Вот при помощи нее и опрашивать?
Можно и при помощи её. Взять, скажем, трассу на пару-тройку гектаров - и постоянно опрашивать. с самого начала. Снижая, тем самым, нагрузку на сервер и сеть.

SomewhereSomehowlocky,

А зачем гектары? Что мешает профайлеру при трассеровке указать размер и количество файлов и опрашивать последний? Ведь там есть все эти параметры...
можно и так. Но зачем мне стопиццоттыщ файлов трассировке по 100 мегабайт?

SomewhereSomehowlockyможно и так. Но зачем мне стопиццоттыщ файлов трассировке по 100 мегабайт?
Какая разница сколько файлов? Было би интересно например воспользоваться всеми бенефитами sp_trace и указывать все параметры в том числе и файлы и т.д. Моя идей в том, чтобы с помощью такого профайлера можно было ы задать трассу, но все "обслуживающие" функции, как то отображение сохранение в таблицу и т.д. профайлер берет на себя, т.е. нагрузка создается только при "отлове" событий, но даже писАться все это дело может на другой диск, при этом всем, профайлер, берет на себя всю ответственность за отображение и запись в таблицу (если указано) и не грузит сервер, открывая курсоры. Пусть, например, пишет на другой сервер или в другую бд.
при чтении файла трассы всё равно будет нагрузка на целевой сервер.
я не до конца понял что такое "открывая курсоры", но пока что не вижу способа, как можно вычитать данные трассы из файла не делая этого (или не зная структуры файла, что, вообще говоря, приводит к ряду дополнительных проблем/ограничений)

Dmitry V. Liseevlockyможно и так. Но зачем мне стопиццоттыщ файлов трассировке по 100 мегабайт?В моем скрипте указано ограничение на размер файла. Там еще время остановки можно указать (у меня закомментировано). Вы же понимаете, что интерактивность тут не главное. Рассмотрим сценарий: у заказчика за 1000 км что-то тормозит. Вам нужно отправить ему по электронной почте скрипт, с инструкцией, как его запустить. Потом он сожмет зипом получившийся файл и отошлет обратно. Вы у себя на рабочем месте сможете этот файл проанализировать, чтобы понять, что именно у заказчика там тормозит. То есть профайлить на продакшн-сервере в реальном времени и устанавливать туда дополнительный софт просто нет возможности.
Хм... Давайте рассмотрим ситуацию: разработчик, работающий с экспрессом (и, возможно - экспресс студией)
Ему надо отрассировать запросы. А нечем. И вот тут появляется экспресс-профайлер, который есть чем.
Все остальные кейсы выпадают из самого предназначения этого профайлера.

SomewhereSomehowlockyпри чтении файла трассы всё равно будет нагрузка на целевой сервер.
я не до конца понял что такое "открывая курсоры", но пока что не вижу способа, как можно вычитать данные трассы из файла не делая этого (или не зная структуры файла, что, вообще говоря, приводит к ряду дополнительных проблем/ограничений) Кто мешает выделить под трассу отдельный диск? И в любом случае, нагрузка только на чтение меньше нагрузки на запись в таблицу у классического профайлера, так что рассмотрите варианты, может еще плюшек дадут, да и разрабы спасибо скажут =)
Если честно, я уже запутался окончательно - кто где и как позволить снизить нагрузку.
Что касается плюшек - уже врядли.