Какой ваш любимый метод для отладки хранимых процедур MS SQL?

Question

Большинство моих SP могут быть просто выполнены (и протестированы) с данными, введенными вручную. Это хорошо работает, и использование простых операторов PRINT позволяет мне "отлаживать".

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

У меня небольшой опыт работы с профилировщиком, но я не нашел способа исследовать, что происходит построчно в моих хранимых процедурах.

Какие у вас методы?

Спасибо, как всегда.

Примечание. Я предполагаю использование SQL Server 2005 +

Answer 1

Профилировщик очень удобен, просто добавьте события SP: StmtStarting и отфильтруйте активность до всего вашего процесса, установив SPID = xxx. Как только вы это настроите, очень легко увидеть, что происходит.

Answer 2

На самом деле вы можете подключить отладчик к вашему серверу sql :) - из vs, если вы настроили его на вашем сервере sql.

Проверьте эту ссылку для получения дополнительной информации, обратите внимание, что вы можете установить точки останова :) https://web.archive.org/web/20090303135325/http://dbazine.com/sql/sql-articles/cook1.

Проверьте эту ссылку для более общего набора информации: http://msdn.microsoft.com/en-us/library/zefbf0t6.aspx

Обновление: Относительно "Однако существуют случаи, когда задействовано более одной хранимой процедуры, и поиск допустимых данных для ввода утомителен. Проще просто инициировать события из моего веб-приложения".

Я предлагаю вам настроить интеграционные тесты, ориентированные на конкретные методы, которые взаимодействуют с этими процедурами. Если процедуры управляются веб-приложением, это отличное место, чтобы иметь действительные тесты + входные данные, которые вы можете запустить в любое время. Если есть несколько приложений, которые взаимодействуют с процедурами, я бы вместо этого посмотрел на модульное тестирование процедур.

Answer 3

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

Answer 4

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

Тем не менее, MS KB 316549 описывает, как использовать Visual Studio для отладки хранимых процедур.

Согласно этой статье, существует ряд ограничений для отладки таким способом:

• Вы не можете "прервать" исполнение.
• Вы не можете «редактировать и продолжить».
• Вы не можете изменить порядок выполнения оператора.
• Хотя вы можете изменить значение переменных, ваши изменения могут не вступить в силу, поскольку значения переменных кэшируются.
• Вывод из оператора SQL PRINT не отображается.

Редактировать : Очевидно, что если вы являетесь человеком, который делает этот сохраненный процесс, то не делайте его "многоуровневым, циклическим перемещением курсора, использованием временной таблицы и вложенным ». Однако в моей роли администратора баз данных это почти то, с чем я ежедневно сталкиваюсь от разработчиков приложений.

Answer 5

Убедитесь, что вы входите в основной сохраненный процесс в VS2005 / 2008, когда он сталкивается с вложенной функцией, нажмите F11 (шаг в), чтобы войти в ... продолжить отладку ... Это было не очень очевидно из меню отладки.

Answer 6

Этот трюк очень удобен:

Настраиваемые пользователем события профилировщика

Answer 7

Моя команда использует SP по правилу как наш интерфейс к базе данных; мы делаем это так, чтобы пользователь приложения мог ТОЛЬКО выполнять SP (с нашим соглашением об именах).

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

Всегда, ВСЕГДА проверяйте SP как можно более тщательно, без какого-либо прикладного уровня (например, через Management Studio).

Answer 8

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