Как получить значения параметров для запроса SQL Server в SQL Server Profiler

Я пытаюсь проанализировать тупик в профилировщике SQL Server 2008. Я знаю, как найти неправильные запросы sql, но собранные запросы не содержат значений параметров.

Другими словами, я вижу что-то вроде этого:

DELETE FROM users WHERE id = @id

Но я бы хотел увидеть вот что:

DELETE FROM users WHERE id = 12345

Я предполагаю, что есть некоторые дополнительные события или столбцы, которые мне нужно собрать в профилировщике, но я не знаю, какие. В настоящее время я использую шаблон «TSQL_LOCKS».

Приветствуются любые подсказки.

Спасибо,

Адриан

Отказ от ответственности: я задавал аналогичный вопрос раньше, но я думаю, он был слишком конкретным, поэтому я не получил ответов. Я начинаю еще одну попытку с этим.


sql-server sql-server-2008 sql-server-profiler
person Adrian Grigore    schedule 23.12.2009    source источник

Ответы (4)


arrow_upward
21
arrow_downward

Думаю, вам нужно событие RPC: Completed:

http://msdn.microsoft.com/en-us/library/ms175543.aspx

person davek    schedule 23.12.2009

arrow_upward
5
arrow_downward

Профилировщик будет содержать значения параметров в RPC: Completed / RPC: запуск событий. Но вы уже получили ответы об этом.

Что я хочу добавить, так это то, что очень мало нужно знать значения параметров во время выполнения, чтобы анализировать график взаимоблокировок. Во-первых, потому что, если в тупик вовлечены «пользователи», сам граф тупиковых ситуаций выдаст, какой @id является конфликтом, если конфликт связан с ключом. Во-вторых, что более важно, для сценария тупика не имеет значения, какие именно ключи задействованы. Это не похоже на то, что тупик происходит из-за удаления пользователя с идентификатором 123, но не произойдет, когда он удалит пользователя 321.

Если вы в первую очередь решили спросить о SO, я думаю, что лучше всего было бы опубликовать фактический график тупиков и позволить сообществу взглянуть на него. Здесь есть многие, кто может ответить на немало вопросов только с помощью XML-графа тупиковых ситуаций.

person Remus Rusanu    schedule 23.12.2009
comment
Кстати, если вы решите опубликовать весь график, а не только половину (?), Пожалуйста, публикуйте фактический график тупиков, а не его изображение. т.е. XML события взаимоблокировки, а не снимок экрана визуализированного изображения. Очень много информации теряется во время рендеринга. - person Remus Rusanu; 23.12.2009
comment
Спасибо за ответ, но я думаю, что это недоразумение. Картинка, на которую я указал в другом посте, не с моего компьютера. Я получил это из учебника по использованию профилировщика SQL-сервера. Он показывает значения параметров во всплывающей подсказке графика, тогда как всплывающие подсказки моего собственного графика включают только запросы, но не значения параметров. Вот почему я разместил свой вопрос. - person Adrian Grigore; 23.12.2009
comment
@ Адриан: всегда заглядывайте в XML для анализа. Графический рендеринг в SSMS - это просто беглый взгляд. Сохраните событие (щелкните его правой кнопкой мыши), а затем откройте сохраненный файл как обычный XML. - person Remus Rusanu; 23.12.2009

arrow_upward
1
arrow_downward

Начните трассировку со следующих событий с установленными флажками:

SQL: BatchCompleted
SQL: BatchStarting
Deadlock graph
Lock:Deadlock
Lock:Deadlock chain

После возникновения взаимоблокировки остановите трассировку, затем щелкните класс событий графа взаимоблокировок.

Это должно дать вам хорошее представление о том, что идет не так.

person Bravax    schedule 23.12.2009
comment
Спасибо, но я это уже знаю. Проблема в том, что график взаимоблокировки не содержит значений параметров, а только запрос, как описано здесь: stackoverflow.com/questions/1952830/ - person Adrian Grigore; 23.12.2009

arrow_upward
1
arrow_downward

Если вы используете хранимую процедуру (которая выглядит так, как вы) или Hibernate / NHibernate, вам может потребоваться включить событие запуска хранимых процедур (SP: StmtStarting) и событие RPC: Starting. Это покажет параметры в отдельной строке после запроса.

Что-то типа:

SP: StmtStarting DELETE FROM users WHERE id = @id

RPC: запуск exec sp_execute 12345

person MkUltra    schedule 23.12.2009
comment
Спасибо за подсказку! Я не использовал SP в этом случае, но это все равно полезно знать. - person Adrian Grigore; 23.12.2009