Мониторинг работы ms sql server. Простой мониторинг активности SQL Server

Любому администратору баз данных, наверняка, приходилось сталкиваться с тем, что все работает медленно, или не работает вообще. Первое, что при этом нужно выяснить - это что вообще происходит на SQL Server в данный момент. Казалось, бы в арсенале администратора множество инструментов: Activity Monitor, Dynamic Management Views (dmv), хранимые процедуры sp_who и sp_who2, оставшиеся в наследство еще со времен SQL Server 7 и SQL Server 2000.
Но, давайте разберемся с мониторингом SQL Server.

Средства мониторинга

Activity Monitor

Занимается мониторингом текущей активности. Запускаете тяжелый бухгалтерский отчет и смотрите что покажет Activity Monitor.
На скриншотах монитор активности от SQL Server 2005:

И от SQL Server Denali (2012) CTP 3.

Сложность анализа заключается в том, что данным инструментом не очень удобно пользоваться, если множество пользователей работаем с ним обновременно. Разбираться будет довольно сложно, хотя, конечно, прогресс на лицо. В Denali Activity Monitor показывает намного больше полезной информации (например на каком конкретно ресурсе происходит ожидание), плюс, мы можем, например, для нужной сессии запустить профайлер прямо из монитора и отслеживать ее уже в профайлере, но, он дополнительно нагружает и без того нагруженный сервер. К тому же проблема с медленной работой уже присутствует, а те запросы, которые на момент запуска профайлера уже начали выполняться, мы не увидим.
Хотелось бы видеть кто и что выполняет именно сейчас.

sp_who и sp_who2

На скриншоте результат выполнения sp_who (сверху) и sp_who2 (снизу), выполненных во время построения все того же отчета:

Данное представление информации не очень информативно. Глядя на sp_who мы можем увидеть только то, что что-то выполняется или несколько каких-то SELECT’ов.
sp_who2 показывает уже больше информации. Теперь мы можем видеть сколько процессорного времени затрачено сессией (и столбиком сложить суммарное время, видимо), количество i/o-операций, имя базы данных в которой все это выполняется и кем заблокирована эта сессия (если она заблокирована).
Activity Monitor, как мы видим, дает больше информации.

DMV

Начиная с SQL Server 2005, мы получили новую возможность получать информацию о состоянии сервера - Dynamic Management Views . MSDN говорит так: «Динамические административные представления и функции возвращают данные о состоянии сервера, которые могут использоваться для контроля исправности экземпляра сервера, диагностики проблем и настройки производительности.».
И действительно, в 2005-м SQL Server’е есть набор представлений, связанных с выполнением запросов в текущий момент (впрочем, для просмотра «истории» тоже есть представления): вот они . И их количество, от версии к версии продолжает увеличиваться!
Наверняка, у опытных администраторов есть наготове куча скриптов, позволяющих получить информацию о текущем состоянии сервера, но что делать, если опыта работы с DMV еще нет, а проблемы уже есть?

sp_WhoIsActive

Adam Machanic (SQL Server MVP и MCITP) разработал и постоянно дорабатывает хранимую процедуру sp_WhoIsActive, которая опирается как раз на эти самые DMV и очень легка в освоении. Скачать последнюю версию sp_WhoIsActive можно . У самого Адама есть цикл статей, посвященных sp_WhoIsActive, состоящий аж из 30 (тридцати!) штук, почитать его можно , а я же, постараюсь заинтересовать вас в прочтении этого материала:).
Итак, будем считать, что вы скачали и запустили этот скрипт на одном из тестовых серверов (на любой версии, начиная с 2005 и заканчивая Denali). Адам советует хранить ее в системной базе данных master, чтобы ее можно было вызвать в контексте любой БД, но это не обязательно, просто при вызове ее в контексте другой БД, придется писать название полностью - БД.схема.sp_whoIsActive.
Итак, попробуем. На скриншоте результат ее выполнения во время построения все того же отчета:

Результат запроса exec sp_whoIsActive, увы, не влазит в один экран, поэтому вот текстовое описание вывода хранимой процедуры, вызываемой без параметров.

- для активного запроса показывает время выполнения, для «спящей» сессии - время «сна»;
- собственно, spid;
- показывает текст выполняемого сейчас запроса, либо текст последнего выполненного запроса, если сессия спит;
- ну, вы поняли;
- очень интересный столбец. Он выводится в формате (Ax: Bms/Cms/Dms)E. А - это количество ожидающих задач на ресурсе E. B/C/D - это время ожидания в миллисекундах. Если ожидает освобождения ресурса всего одна сессия (как на скриншоте), будет показано ее время ожидания, если 2 сессии - их времена ожидания в формате B/C. Если же ожидают 3 и более - мы увидим минимальное, среднее и максимальное время ожидания на ЭТОМ ресурсе в формате B/C/D;
- для активного запроса - суммарное время ЦП, затраченное этим запросом, для спящей сессии - суммарное время ЦП за «всю жизнь» этой сессии;
- для активного запроса - это количество операций записи в TempDB за время выполнения запроса; для спящей сессии - суммарное количество записей в TempDB за все время жизни сессии;
- для активного запроса - количество страниц в TempDB, выделенных для этого запроса; для спящей сессии - суммарное количество страниц в TempDB, выделенных за все время жизни сессии;
- если вдруг мы кем-то заблокированы, покажет spid (session_id) того, кем мы заблокированы;
- для активного запроса - количество логических чтений выполненных при выполнении этого запроса; для спящей сессии - количество прочитанных страниц за все время жизни этой сессии;
- все тоже самое, но про запись;
- для активного запроса - количество физических чтений, выполненных при выполнении этого запроса; для спящей сессии - традиционно, суммарное количество физических чтений за все время жизни сессии;
- для активного запроса - количество восьмикилобайтовых страниц, использованных при выполнении этого запроса; для спящей сессии - сколько суммарно страниц памяти выделялось ей за все ее время жизни;
- статус сессии - выполняется, спит и т.д.;
- показывает количество транзакций открытых этой сессией;
- показывает, если есть такая возможность, процесс выполнения операции (например, BACKUP, RESTORE), никогда не покажет на сколько процентов выполнен SELECT .

Остальные столбцы в стандартном выводе sp_WhoIsActive малоинтересны, и описывать их я не буду - их назначение, я думаю, понятно всем (host_name, database_name, program_name, start_time, login_time, request_id, collection_time).
Но это еще не все. Еще я расскажу о том с какими (наиболее интересными и полезными, с моей точки зрения) параметрами можно вызывать sp_WhoIsActive и что из этого получится.

@help - это ужасно полезный параметр. При вызове sp_whoIsActive @help = 1 , мы получаем на экран информацию обо ВСЕХ параметрах и выводимых столбцах. Так что если что-то останется непонятным, всегда можно посмотреть «помощь»
@filter_type и @filter - позволяют отфильтровать результат выполнения. @filter_type может принимать значения ‘session’, ‘program’, ‘database’, ‘login’ и ‘host’. В параметре @filter мы указываем какой именно объект выбранного типа нас интересует. Например, мы хотим увидеть все сессии, выполняющиеся в БД master, для этого вызываем exec sp_whoIsActive @filter_type = "database", @filter = "master" . В параметре @filter допустимо использование «%»;
@not_filter_type и @not_filter - позволяют нам фильтровать «наоборот». Т.е., например, мы хотим видеть все, кроме тех сессий, у которых в поле «database» стоит ‘master’, для этого выполняем exec sp_WhoIsActive @not_filter_type = "database", @not_filter = "master" . Ну, или, мы захотим увидеть что выполняют все пользователи кроме пользователя sa… Применений может быть множество. В параметре @not_filter допустимо использование «%»;
@show_system_spids = 1 - покажет информацию о системных сессиях;
@get_full_inner_text = 1 - в поле sql_text будет находиться не просто текст текущего запроса (стэйтмента) в пакете (батче), а текст всего батча целиком;
@get_plans - добавит к выводу столбец с планами выполнения запросов;
@get_transaction_info = 1 - добавит к выводу количество и объем записей в журналы транзакций, а так же время начала последней транзакции;
@get_locks = 1 - добавит к выводу информацию о всех блокировках, наложенных во время выполнения запроса;
@find_block_leaders = 1 - проследит цепочку блокировок и покажет суммарное количество сессий, ожидающих снятия блокировки текущей сессией;
@output_column_list = "[%]" - а вдруг вы не хотите видеть информацию о tempDB в выводе sp_whoIsActive? С помощью этого параметра можно управлять тем, что она выводит;
@destination_table = "table_name" - попытается вставить результат выполнения записать в таблицу, но не будет проверять существует ли эта таблица и хватает ли прав на вставку в нее.

Начиная с версии 2008 в сборку SQL Server был добавлен монитор производительности системы - Performance Data Collector (PDC). Новый компонент Management Studio, призванный облегчить мониторинг и настройку производительности экземпляров SQL Server"а конечным пользователям.

Компоненты, устанавливаемые по умолчанию, называют набором системы сбора данных, а именно:

Использование дискового пространства. Сбор данных об использовании дискового пространства в базе данных.
Статистика запросов . Отчеты о статистики запросов , индивидуальный текст запроса , планы запросов , и конкретных запросов .
Мониторинг активности сервера . Собирает статистику использования ресурсов и производительности данных с сервера , операционной системы и SQL сервера .

Преимущества:

Простота конфигурации . Конфигурация требует всего несколько кликов .
Простота отслеживания событий, тестирования и мониторинга общего состояния системы.
Централизованное хранение данных .
Адаптивность. Включена возможность создания собственной системы сбора данных

Ограничения:

Совместимо только с версией SQL Server 2008.
Система сбора данных не отображает информацию о дисковом пространстве в режиме онлайн

Этапы подготовки:

На первом этапе подготовки на сервере должна быть создана папка с правами на чтение/запись для службы SQLSERVERAGENT. Вся техническая информация будет собираться в данной папке, а затем загружаться в базу данных системы мониторинга.
База данных системы мониторинга должна быть создана до того, как вы запустите мониторинг. Данная база данных по сути является обычной базой данных SQL и содержит все данные, полученные с помощью системы мониторинга.
Позаботьтесь заранее о размере дискового пространства. Ожидаемый рост базы данных около 250 - 350 мб в день.
По умолчанию данные очищаются каждые 14 дней. Глубину очистки можно менять в зависимости от заданных требований.
Набор сбора "Занято место на диске" отслеживает рост базы данных и файлов журнала и предоставляет статистику по файлам, такую как средний рост (в мегабайтах) в день. Опрос состояния диска происходит каждые 5 секунд, каждый час данные записываются в базу данных и хранятся в течение 90 дней. Данные интервалы могут быть скорректированы.
Набора сбора "Статистика запросов" собирает данные по статистике запросов, а также тексты отдельных запросов, планы запросов и конкретные запросы. Эти данные в сочетании с системой статистикой и действиями позволяют проводить детализацию углублением ниже уровня сеанса к отдельным запросам. Частота передачи по расписанию - каждые 15 минут, хранение данных в течение 14 дней. Данные интервалы могут быть скорректированы.
Набор сбора "Активность сервера" предоставляет общие сведения об активности SQL Server, использовании ресурсов SQL Server и конфликта между ресурсами SQL Server. Этот набор сбора также дает инкапсулированное представление использования всех системных ресурсов, которые позволяет определить связь проблем производительности с действиями за пределами области SQL Server. Запись статистики активности сервера происходит каждые 60 секунд, для активных сессий и запросов данный интервал составляет 10 секунд
База данных MSDB используется для хранения информации о конфигурации, о времени выполнения, аудита и ведении журнала сбора информации. SSIS пакетов хранятся в MSDB.
Необходимо обязательно установить SQL Server agent.
Служба интеграции SQL Server должна быть запущена, т.к. SSIS пакеты используются для сбора данных. SSIS пакеты также генерируют события во время сбора данных, которые используются для мониторинга и устранения неполадок в процессе сбора.
Data Collector Security. В окне мастера "Configure Data Warehouse Wizard" необходимо сопоставить роли для сборщика данных и учетные записи пользователей. К ним относятся: mdw_admin, mdw_reader и mdw_writer.

mdw_reader - используется для входа пользователям, которым необходимо архивные отчеты;
mdw_writer - роль может загружать и записывать данные в хранилище данных. Поэтому каждая служба SQLServerAgent, используемая на удаленных сборщиках данных, хранит данные в центральном базе данных.
mdw_admin - чтение, запись, обновление и удаление доступа к базе данных. Любая учетная запись пользователя назначенная на роль mdw_admin может изменить схему на mdw-файла и запускать задания по обслуживанию.

Настройка производительности Data Collector

Во-первых, создадим хранилище данных управления

Теперь, давайте настроим хранилище данных управления.

Нажимаем "Next" на экране приветствия

Указываем имя базы данных и место расположения

Присваиваем пользователю роль mdw_admin.

Проверяем конфигурацию. Если все указано правильно, нажимаем "Finish" и переходим к процессу конфигурирования.

Идет процесс конфигурации...

Конфигурация выполнена.

Теперь, после выполнения на сервере запросов к базе данных можно просмотреть отчеты этих выполнений. Для просмотра отчетов разверните вкладку "Management" -> "Data Collection".

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

Здесь же можно увидеть сводный отчет об использовании дискового пространства.

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

История статистики запросов.

Этот отчет отображает ресурсоемкие запросы по категориям.

Вы можете нажать на любой запрос и получить подробную информацию по данному запросу.

Внизу расположена подробная информация по выбранному запросу.

Вопрос такой... кто и как использует монитор активности? для чего? есть какие-нибудь примеры? там все процессы AWAITING COMMAND читал, что завершать их не рекомендуется, зачем тогда нужен этот монитор??? просто ради интереса?

и еще, как можно проследить за действиями пользователей?

Что ты хочешь отслеживать?

Если историю посомтреть с графиками то это Data Collection

Если надо на данный момент посомреть то можно пользоваться Data management View а ля

SELECT * FROM sys.dm_exec_sessions AS des

SELECT * FROM sys.dm_exec_requests AS der

или по старинке exec sp_who

либо запустить монитор активности =)

Судя по тому что ты там ничего не видишь, то на сервере у вас 1 запрос в час, который SQL смело делает.

Спрашивается зачем что-то завершать? Если уж на то пошло сессии ниже 50 - это системные службы и на них думаю пока не стоит замахиватьсяч если не понимаешь что делаешь.

Для начала попробуй вот так

SELECT * FROM sys.dm_exec_requests AS der WHERE der.session_id > 50

Если посомтришь что тебе монитор активности показывает то увидишь знакомые таблички...

SELECT = s.session_id, = CONVERT(CHAR(1), s.is_user_process), = s.login_name, = ISNULL(db_name(p.dbid), N""), = ISNULL(t.task_state, N""), = ISNULL(r.command, N""), = ISNULL(s.program_name, N""), = ISNULL(w.wait_duration_ms, 0), = ISNULL(w.wait_type, N""), = ISNULL(w.resource_description, N""), = ISNULL(CONVERT (varchar, w.blocking_session_id), ""), = CASE -- session has an active request, is blocked, but is blocking others or session is idle but has an open tran and is blocking others WHEN r2.session_id IS NOT NULL AND (r.blocking_session_id = 0 OR r.session_id IS NULL) THEN "1" -- session is either not blocking someone, or is blocking someone but is blocked by another party ELSE "" END, = s.cpu_time, = (s.reads + s.writes) * 8 / 1024, = s.memory_usage * 8192 / 1024, = ISNULL(r.open_transaction_count,0), = s.login_time, = s.last_request_start_time, = ISNULL(s.host_name, N""), = ISNULL(c.client_net_address, N""), = ISNULL(t.exec_context_id, 0), = ISNULL(r.request_id, 0), = ISNULL(g.name, N"") FROM sys.dm_exec_sessions s LEFT OUTER JOIN sys.dm_exec_connections c ON (s.session_id = c.session_id) LEFT OUTER JOIN sys.dm_exec_requests r ON (s.session_id = r.session_id) LEFT OUTER JOIN sys.dm_os_tasks t ON (r.session_id = t.session_id AND r.request_id = t.request_id) LEFT OUTER JOIN (-- In some cases (e.g. parallel queries, also waiting for a worker), one thread can be flagged as -- waiting for several different threads. This will cause that thread to show up in multiple rows -- in our grid, which we don"t want. Use ROW_NUMBER to select the longest wait for each thread, -- and use it as representative of the other wait relationships this thread is involved in. SELECT *, ROW_NUMBER() OVER (PARTITION BY waiting_task_address ORDER BY wait_duration_ms DESC) AS row_num FROM sys.dm_os_waiting_tasks) w ON (t.task_address = w.waiting_task_address) AND w.row_num = 1 LEFT OUTER JOIN sys.dm_exec_requests r2 ON (s.session_id = r2.blocking_session_id) LEFT OUTER JOIN sys.dm_resource_governor_workload_groups g ON (g.group_id = s.group_id) LEFT OUTER JOIN sys.sysprocesses p ON (s.session_id = p.spid) ORDER BY s.session_id;

Ну и счетчики производительности тоже никто не отменял. А ля количество запросов в секунду и т.д.

Любому администратору баз данных, наверняка, приходилось сталкиваться с тем, что все работает медленно, или не работает вообще. Первое, что при этом нужно выяснить - это что вообще происходит на SQL Server в данный момент. Казалось, бы в арсенале администратора столько всяких полезных штук: гуевый Activity Monitor, куча Dynamic Management Views (dmv), хранимые процедуры sp_who и sp_who2, оставшиеся в наследство еще со времен SQL Server 7 и SQL Server 2000.
Но, давайте разберемся…

Средства мониторинга

Activity Monitor

Казалось бы, отличная штука, занимается как раз тем чем надо - мониторит активность. Запускаю тяжелый бухгалтерский отчет и смотрю что мне покажет Activity Monitor.
На скриншотах монитор активности от SQL Server 2005:

И от SQL Server Denali (2012) CTP 3.

М-да. А если десяток человек запустит такие отчеты? А это ведь не редкость… Разбираться будет довольно неудобно, хотя, конечно, прогресс на лицо. В Denali Activity Monitor показывает намного больше полезной информации (например на каком конкретно ресурсе происходит ожидание), плюс, мы можем, например, для нужной сессии запустить профайлер прямо из монитора и отслеживать ее уже в профайлере, но, черт побери, он дополнительно нагружает и без того нагруженный сервер. К тому же проблема с тормозами уже есть, а те запросы которые на момент запуска профайлера уже начали выполняться, мы не увидим.
А я хочу видеть именно это - кто и что выполняет именно сейчас.

sp_who и sp_who2

На скриншоте результат выполнения sp_who (сверху) и sp_who2 (снизу), выполненных во время построения все того же злосчастного отчета:

Ага. Очень информативно. Глядя на sp_who мы можем увидеть только то, что что-то выполняется. Конечно выполняется - мы ж для того и смотрим, а видим, что выполняется какой-то SELECT. Или несколько каких-то SELECT"ов. Здорово.
sp_who2 показывает уже больше информации. Теперь мы можем видеть сколько процессорного времени затрачено сессией (и столбиком сложить суммарное время, видимо), количество i/o-операций, имя базы данных в которой все это выполняется и кем заблокирована эта сессия (если она заблокирована).
Activity Monitor, как мы видим, дает больше информации.

DMV

Начиная с SQL Server 2005, мы получили новую возможность получать информацию о состоянии сервера - Dynamic Management Views . MSDN говорит так: «Динамические административные представления и функции возвращают данные о состоянии сервера, которые могут использоваться для контроля исправности экземпляра сервера, диагностики проблем и настройки производительности.».
И действительно, в 2005-м SQL Server"е есть набор представлений, связанных с выполнением запросов в текущий момент (впрочем, для просмотра «истории» тоже есть представления): вот они . И их количество, от версии к версии продолжает увеличиваться!
Наверняка, у мастистых администраторов есть наготове куча скриптов, позволяющих получить информацию о текущем состоянии сервера, но что делать, если опыта работы с DMV еще нет, а проблемы уже есть?

sp_WhoIsActive

Adam Machanic (SQL Server MVP и MCITP) разработал и постоянно дорабатывает хранимую процедуру sp_WhoIsActive, которая опирается как раз на эти самые DMV и чертовски легка в использовании. Скачать последнюю версию sp_WhoIsActive можно . У самого Адама есть цикл статей, посвященных sp_WhoIsActive, состоящий аж из 30 (тридцати!) штук, почитать его можно , а я же, постараюсь заинтересовать вас в прочтении этого материала:).
Итак, будем считать, что вы скачали и запустили этот скрипт на одном из тестовых серверов (на любой версии, начиная с 2005 и заканчивая Denali). Адам советует хранить ее в системной базе данных master, чтобы ее можно было вызвать в контексте любой БД, но это не обязательно, просто при вызове ее в контексте другой БД, придется писать название полностью - БД.схема.sp_whoIsActive.
Итак, попробуем. На скриншоте результат ее выполнения во время построения все того же отчета:

Результат запроса exec sp_whoIsActive, увы, не влазит в один экран, поэтому вот текстовое описание вывода хранимой процедуры, вызываемой без параметров.

- для активного запроса показывает время выполнения, для «спящей» сессии - время «сна»;
- собственно, spid;
- показывает текст выполняемого сейчас запроса, либо текст последнего выполненного запроса, если сессия спит;
- ну, вы поняли;
- очень интересный столбец. Он выводится в формате (Ax: Bms/Cms/Dms)E. А - это количество ожидающих задач на ресурсе E. B/C/D - это время ожидания в миллисекундах. Если ожидает освобождения ресурса всего одна сессия (как на скриншоте), будет показано ее время ожидания, если 2 сессии - их времена ожидания в формате B/C. Если же ожидают 3 и более - мы увидим минимальное, среднее и максимальное время ожидания на ЭТОМ ресурсе в формате B/C/D;
- для активного запроса - суммарное время ЦП, затраченное этим запросом, для спящей сессии - суммарное время ЦП за «всю жизнь» этой сессии;
- для активного запроса - это количество операций записи в TempDB за время выполнения запроса; для спящей сессии - суммарное количество записей в TempDB за все время жизни сессии;
- для активного запроса - количество страниц в TempDB, выделенных для этого запроса; для спящей сессии - суммарное количество страниц в TempDB, выделенных за все время жизни сессии;
- если вдруг мы кем-то заблокированы, покажет spid (session_id) того, кем мы заблокированы;
- для активного запроса - количество логических чтений выполненных при выполнении этого запроса; для спящей сессии - количество прочитанных страниц за все время жизни этой сессии;
- все тоже самое, но про запись;
- для активного запроса - количество физических чтений, выполненных при выполнении этого запроса; для спящей сессии - традиционно, суммарное количество физических чтений за все время жизни сессии;
- для активного запроса - количество восьмикилобайтовых страниц, использованных при выполнении этого запроса; для спящей сессии - сколько суммарно страниц памяти выделялось ей за все ее время жизни;
- статус сессии - выполняется, спит и т.д.;
- показывает количество транзакций открытых этой сессией;
- показывает, если есть такая возможность, процесс выполнения операции (например, BACKUP, RESTORE), никогда не покажет на сколько процентов выполнен SELECT .

И чО? Это все?

Нет, это еще не все. Еще я расскажу о том с какими (наиболее интересными и полезными, с моей точки зрения) параметрами можно вызывать sp_WhoIsActive и что из этого получится.

@help - это ужасно полезный параметр. При вызове sp_whoIsActive @help = 1 , мы получаем на экран информацию обо ВСЕХ параметрах и выводимых столбцах. Так что если что-то останется непонятным, всегда можно посмотреть «помощь»
@filter_type и @filter - позволяют отфильтровать результат выполнения. @filter_type может принимать значения "session", "program", "database", "login" и "host". В параметре мы указываем какой именно объект выбранного типа нас интересует. Например, мы хотим увидеть все сессии, выполняющиеся в БД master, для этого вызываем exec sp_whoIsActive @filter_type = "database", = "master" . В параметре допустимо использование "%";
@not_filter_type и @not_filter - позволяют нам фильтровать «наоборот». Т.е., например, мы хотим видеть все, кроме тех сессий, у которых в поле «database» стоит "master", для этого выполняем exec sp_WhoIsActive @not_filter_type = "database", @not_filter = "master" . Ну, или, мы захотим увидеть что выполняют все пользователи кроме пользователя sa… Применений может быть множество. В параметре @not_filter допустимо использование "%";
@show_system_spids = 1 - покажет информацию о системных сессиях;
@get_full_inner_text = 1 - в поле sql_text будет находиться не просто текст текущего запроса (стэйтмента) в пакете (батче), а текст всего батча целиком;
@get_plans - добавит к выводу столбец с планами выполнения запросов;
@get_transaction_info = 1 - добавит к выводу количество и объем записей в журналы транзакций, а так же время начала последней транзакции;
@get_locks = 1 - добавит к выводу информацию о всех блокировках, наложенных во время выполнения запроса;
@find_block_leaders = 1 - проследит цепочку блокировок и покажет суммарное количество сессий, ожидающих снятия блокировки текущей сессией;
@output_column_list = "[%]" - а вдруг вы не хотите видеть информацию о tempDB в выводе sp_whoIsActive? С помощью этого параметра можно управлять тем, что она выводит;
@destination_table = "table_name" - попытается вставить результат выполнения записать в таблицу, но не будет проверять существует ли эта таблица и хватает ли прав на вставку в нее.

Вот теперь все

В итоге, мы имеем еще один чрезвычайно удобный и гибкий инструмент для отслеживания текущей активности на SQL Server. Для нормальной его работы вполне достаточно разрешения VIEW SERVER STATE и прав на обращение к dmv.
Стоит также добавить, в том случае, когда к серверу возможно подключение только по