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

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

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

DELETE FROM users WHERE id = @id

Но я хотел бы видеть следующее:

DELETE FROM users WHERE id = 12345

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

Любые подсказки будут очень признательны.

Спасибо,

Адриан

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

ОТВЕТЫ

Ответ 2

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

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

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

Ответ 3

Запустите трассировку со следующими событиями, отмеченными всеми флажками:

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

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

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

Ответ 4

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

Что-то вроде:

SP: StmtStarting DELETE FROM users WHERE id = @id

RPC: запуск exec sp_execute 12345