Каков наилучший способ отладки хранимых процедур (и записи sprocs, которые легче отлаживать)?

Question

Каковы хорошие методологии для создания sprocs, которые уменьшают трудность отладки? И какие есть инструменты для отладки хранимых процедур?

Возможно, самое главное, каковы признаки того, что ошибки происходят в sproc, а не в коде? Надеюсь, я здесь не так уж и плох. Голосует за ответы на любые из вышеперечисленных. Спасибо.

Что бы это ни стоило, я работаю в среде .NET, на серверах SQL.

Answer 1

Один метод, который я использую в хранимых процедурах, чтобы облегчить их отладку (без IDE или отладчиков) для процедур SQL Server 2005:

Я добавляю входной параметр с именем @Debug = 0 (по умолчанию 0 = выкл) в конце списка параметров для процедуры.

Затем я добавляю if (@Debug = 1) print '...';

операторов в коде на ключевых этапах для отображения любых полезных внутренних значений и т. Д.

Да, это "старая школа" и отладчики, которые позволяют вам "обходить код" - это прекрасно, но это работает для любого, кто использует любой инструмент SQL (включая тех, кто отлаживает без вашей IDE).

Рон

Answer 2

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

   --**************************************************************************
   -- Create a log table variable to store messages to be returned to the
   -- calling application.
   --**************************************************************************
   declare @log             as table ( msg  varchar(MAX) );

then

     insert into @log values ('Inserted a new DVO Order into IRMA, order id: [' + convert(varchar(10), @@IDENTITY ) + ']');
etc.

then ...

   select msg from @log;
end

в конце процедуры - это зависит от того, насколько хорошо вызывающее приложение регистрирует выходные данные вашего вызова процедуры, но приложение, которое я написал, записывает все это. : -)

Answer 3

Я настоятельно рекомендую вам взглянуть на встроенный инструментарий в SQL Management Studio.

Я написал довольно подробный пост в блоге об этом здесь:

http://www.diaryofaninja.com/blog/2010/11/23/debugging-sql-queries-function-amp-stored-procedures-with-sql-management-studio

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

очень, очень удобно - и никто, кажется, не использует его.

Answer 4

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

DBFit - это просто серия Fit Fixtures, которые можно использовать для тренировки базы данных. Используя Fitness, вы можете записать столько перестановок вызовов в свой сохраненный процесс, сколько вы хотите создать для тестов.

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

Answer 5

TSQLUnit

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

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

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

Answer 6

Это может быть личное предпочтение, но я нахожу чрезвычайно сложным читать запросы SQL, которые все накладываются на одну длинную строку. Я предпочитаю следующий стиль отступов:

SELECT
    [Fields]
FROM
    Table
WHERE
    x = x

Эта простая практика очень помогла мне при написании хранимых процедур для новой схемы базы данных. Разбивая операторы на несколько строк, становится легче идентифицировать виновника ошибки в вашем запросе. Например, в SQL Server Management Studio указывается номер строки исключения, что позволяет гораздо быстрее нацеливать проблемный код.

Будьте проще с вашими коллегами-разработчиками ... не помещайте 800 символов SQL-запроса в одну строку. Позже вы будете благодарны, если имя поля базы данных или тип данных изменятся, и никто не отправит вам электронное письмо.

Answer 7

Для инструментов вы можете использовать Visual Studio для отладки SP. Если хранимый процесс имеет длинную логику, вы можете выполнить его рефакторинг, создать отдельный сохраненный процесс и вызвать его из вашего основного хранимого процесса. Это также поможет сузить ваше тестирование и упростит вам поиск того, какая часть запросов неверна.

Answer 8

Как и в случае с регистрацией Рона, мы вызываем процедуру регистрации через все другие хранимые процедуры, чтобы помочь в отслеживании всех вызовов. Общий BatchId используется повсюду, чтобы разрешить трассировку для определенного пакетного запуска. Возможно, это не самый эффективный процесс, но он действительно помогает отследить ошибки. Также довольно просто составлять сводные отчеты по электронной почте для администраторов.

т.

Select * from LogEvent where BatchId = 'blah'

Пример звонка

EXEC LogEvent @Source='MyProc', @Type='Start'
, @Comment='Processed rows',@Value=50, @BatchId = @batchNum

Основной процесс

CREATE PROCEDURE [dbo].[LogEvent]
    @Source varchar(50),
    @Type varchar(50),
    @Comment varchar(400),
    @Value decimal = null,
    @BatchId varchar(255) = 'BLANK'
AS

IF @BatchId = 'BLANK'
  SET @BatchId = NEWID()

  INSERT INTO dbo.Log
    (Source, EventTime, [Type], Comment, [Value],BatchId)
  VALUES
    (@Source, GETDATE(), @Type, @Comment, @Value,@BatchId)

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

Answer 9

Интегрированный отладчик SQL Server 2008 Management Studio сделал пошаговую отладку проще (сравните дзюдо, необходимое для выяснения, как заставить VS2005 + SQL отлаживать)

Answer 10

Возможно, это не тот ответ, который вы ищете, но если вы уже находитесь в среде .Net, LINQtoSQL значительно уменьшил количество хранимых процедур, которые я пишу / использую / нужно отлаживать.

Сложность отладки SQL - одна из причин, по которой программирование бизнес-логики в LINQ является моей новой предпочтительной практикой.