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

21

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

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

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

Ваш Ответ

13   ответов
2

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

1

говую отладку проще (сравните дзюдо, необходимое для выяснения, как заставить VS2005 + SQL отлаживать)

Могу ли я предположить, что Server Manager Express не имеет этой функции? MrBoJangles
@ MrBoJangles: даже если в редакции Express ее нет, вы можете купить редакцию для разработчиков (функционально эквивалентную редакции Enterprise) за 50 $!
1

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

тестовый или диагностический режимы полезны, когда вы выполняете динамическое выполнение SQL. Убедитесь, что вы можете видеть, что вы собираетесь выполнить. Если у вас есть области, где вы должны (или должны) проверять наличие ошибок, рассмотрите возможность регистрации в таблице с достаточным количеством деталей, чтобы вы могли диагностировать происходящее.

1

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

LEFT JOIN

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

И обязательно проверяйте свои процедуры, когда вносите изменения. Для этого мне нравится помещать простой тестовый запрос в комментарии к процедуре. Обвисулы, я не смог сделать это сегодня :-(

/************************************
  MyProcName

  Test:
  -----
  exec MyProcName @myParam
*************************************/
Хороший совет, чтобы быть уверенным. MrBoJangles
2

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

SELECT
    [Fields]
FROM
    Table
WHERE
    x = x

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

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

8

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

   --**************************************************************************
   -- 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

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

3

TSQLUnit

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

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

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

Согласен, мы используем DbFit и Fitness уже около 8 месяцев, и я не могу себе представить, что когда-либо жил без него.
9

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

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

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

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

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

Рон

1

мы вызываем процедуру регистрации через все другие хранимые процедуры, чтобы помочь в отслеживании всех вызовов. Общий 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 процессов в одну инфраструктуру.

3

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

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

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

6

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, чтобы проходить и переходить к сохраненным процессам.

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

+1: вау Прошло не менее пяти лет с тех пор, как я снова посетил отладку хранимых процедур. Я не знал об этом. Спасибо!
1

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

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

Это то, о чем я не знаю. Мне придется провести некоторое время с LINQ. Благодарю. MrBoJangles
1

но я обнаружил, что это может быть проблемой во всех ситуациях, кроме самых прямых (отладка на локальном сервере и т. Д.). Мне еще предстоит найти что-то лучше, чем операторы print, поэтому я буду с интересом следить за этой веткой.

Да, я тоже. Может быть, какой-то предприниматель может сделать некоторые крайне необходимые инструменты. MrBoJangles

Похожие вопросы