Уважаемый г-н zVlad, существует более чем один способ включить трейсинг в SQL Server, я полагаю, Ваш коллега выбрал самый зрелищный и простой - графический тул, запускаемый на клиенте и высасывающий по сети из сервера довольно большой объем данных, в случае OLTP нагрузки, сравнимый, а то и превышающий размер данных, которые приложения гонят через сеть туда/сюда. Очевидно, что этого делать не стоит в реальной ситуации без того, чтобы сильно ограничить фильтрацией трассу.zVlad wrote: Я полагаю он опасался за performance. Могу переспросить что он имел в виду.
Я нисколько не сомневаюсь что MS SQL оснащен мониторами богато. Но разница в том что в Production все эти мониторы как правило отключаются, а у нас нет - все работают и собирают всю информацию. Единственно от ключается сбор данных для анализа производительности. Точнее включается по необходимости.
Этот DBA имеет сертификаты не только по MS SQL, но и по Oracle, и фактически обе BD администрит. Так что не надо ему "подучиваться". Это в Вашей консерватории в целом проблема.
Альтернатива, которой следует пользоваться аккуратному DBA, это сохранять трассы на сервере в файловой системе (или даже в таблице в базе) с автоматической архивацией файлов с трассами. Что будет иметь очень ограниченное (в большинстве случаев ничтожное) влияние на производительность сервера в целом. Это все прекрасно известно и не составляет какого-то секретного знания.
В общем, SQL Profiler на клиенте без фильтрации это примерно как те ad-hoc запросы на МФ без надлежащих индексов, которые работали сутками вместо десятков секунд. На редкость непрофессионально. Хотя для демонстрации по быстрому, возможно, и терпимо.