Поддержка  •  Дневник  •  Без рекламы  •  О сайте  •  Реклама  •  Поставить баннер  •  Прислать  •  Хроника  •  Translate Гости: 7    Участники: 0 Авторизация Авторизация   Регистрация 
Метод Научного Тыка
RULVEN
Поиск  
Blackball iMag | интернет-журнал
Каталог


Начало » Разработка ПО » Три способа отладки T-SQL кода
Мне повезёт!

Три способа отладки T-SQL кода


Три способа отладки T-SQL кода
Добавлено: Пн 12.06.2023 • Sergeant
Автор: Olesia Dudareva
Источник: источник
Просмотров: 477
Комментарии: 0


Написание нового кода = ошибки. С этим всё просто.

Избавится от ошибок – вот это сложная задача.

Программисты привыкли, что в их средствах разработки есть встроенные инструменты, показывающие, какая строка кода сейчас работает, отображают текущее содержимое переменных, выводят сообщения о процессе выполнения и т. д. Какое-то время в SQL Server Management Studio тоже был отладчик кода, но, начиная с версии SSMS v18, он был удален. Хотя даже когда отладчик был, я не фанател от него: SQL Server буквально мог прекратить обработку других запросов, пока выполнял ваш запрос. Это была катастрофа, особенно когда ваш запрос блокировал других пользователей, и всё это происходило на рабочей базе.

Мне бы хотелось, чтобы у нас был простой способ отладки T-SQL на рабочей базе без блокировок, но отладка T-SQL отличается от отладки в C#. Так что если ваш T-SQL код делает не то, что вы ожидали, вот несколько хороших способов для его отладки.

Вариант 1: Использовать PRINT

С незапамятных времен разработчики вставляли в код такие строки:

BEGIN TRAN
    PRINT 'Starting access date changes'

    UPDATE dbo.Users
        SET LastAccessDate = GETDATE()
        WHERE DisplayName = N'Brent Ozar';

    PRINT 'Done with access date, starting reputation changes'

    UPDATE dbo.Users
        SET Reputation = Reputation / 0
        WHERE DisplayName = N'jorriss';

    PRINT 'Done with reputation changes'
COMMIT

Чтобы видеть в какой части кода возникла ошибка, когда он упадет:

Отладка SQL

У этого подхода есть пара проблем:

  • PRINT не выводит информацию мгновенно. SQL Server кэширует информацию, которая должна быть выведена в Сообщениях. Если вы отлаживаете длительный процесс, скорее всего вам бы хотелось увидеть сообщения об ошибках мгновенно, как только они возникают.
  • PRINT передает данные по сети, хотите вы того или нет, увеличивая накладные расходы ваших запросов. Это не играет большой роли до тех пор, пока вы не превысили 1,000 запросов в секунду, после этого вам захочется везде сократить расходы, где это только возможно. Вы ведь в действительности хотите видеть отладочные сообщения только тогда, когда они вам нужны.

Давайте попробуем улучшить нашу отладку с помощью RAISERROR.

Вариант 2: Использовать RAISERROR, произносится как raise-roar

Что? Вы не знали, что это слово произносится по-другому? Ладно, открою секрет, я тоже не знал, как оно произносится – Грег Лоу (Greg Low) из SQLDownUnder рассказал мне об этом. Давайте усложним наш код:

DECLARE @Debug BIT = 1;

BEGIN TRAN
    IF @Debug = 1
        RAISERROR (N'Starting access date changes', 0, 1) WITH NOWAIT

    UPDATE dbo.Users
        SET LastAccessDate = GETDATE()
        WHERE DisplayName = N'Brent Ozar';

    IF @Debug = 1
        RAISERROR (N'Done with access date, starting reputation changes', 0, 1) WITH NOWAIT

    UPDATE dbo.Users
        SET Reputation = Reputation / 0
        WHERE DisplayName = N'jorriss';

    IF @Debug = 1
        RAISERROR (N'Done with reputation changes', 0, 1) WITH NOWAIT

COMMIT

Я добавил переменную @Debug, и мои статусные сообщения теперь выводятся только тогда, когда @Debug = 1. Конкретно в этом примере мне не нужен параметр – но в ваших рабочих хранимых процедурах и функциях вам точно он будет нужен, только не забудьте указать значение этого параметра по умолчанию равным 0, как в примере ниже:

CREATE OR ALTER PROC dbo.DoStuff
    @MyParam VARCHAR,
    @Debug BIT = 0 AS
...

В этом случае, вы можете включить отладку вручную, когда вам это нужно, при этом приложение не будет вызывать процедуру или функцию с параметром @Debug, таким образом, всегда будет использоваться значение по умолчанию, 0.

Я тоже переключился на RAISERROR с PRINT, потому что у RAISERROR есть полезный параметр WITH NOWAIT, который дает команду SQL Server на отправку статусного сообщения на клиента немедленно, не дожидаясь заполнения буфера.

Когда вы отлаживаете долгий или сложный процесс, возможно, вам захочется динамически управлять статусами сообщений. Предположим, у вас есть хранимая процедура, которая работает часами, и вы хотите понять, какая из ее частей работает дольше всего. Вы не собираетесь там сидеть с секундомером, и вы не собираетесь подойти попозже в надежде, что ваши запросы еще находятся в кэше планов запросов. Вместо этого вам хочется добавить дату/время в сообщение RAISERROR.

К сожалению, RAISERROR не поддерживает объединение строк. Поэтому вы должны передать в RAISERROR только одну строку, которая будет содержать всю нужную вам информация, как показано на примере ниже:

DECLARE @Now NVARCHAR(50);

SET @Now = CONVERT(NVARCHAR(50), GETDATE(), 26);
    RAISERROR (N'Done with reputation changes at %s', 0, 1, @Now) WITH NOWAIT

И это позволит вам получить дату и время на выходе:

Отладка SQL

Вы можете даже передавать несколько аргументов – тут можно найти больше информации о том, как работает RAISERROR.

Вариант 3: Использовать табличные переменные

Возможно, вы слышали от меня или других разработчиков, что использование табличных переменных понижает производительность. В большинстве своем это правда – но иногда они работают очень быстро, как раз об этом мы говорили в этом курсе Fundamentals of TempDB. Тем не менее, у табличных переменных есть одна особенность: они игнорируют транзакции.

BEGIN TRAN
    DECLARE @Progress TABLE (StatusDate DATETIME2, StatusMessage NVARCHAR(4000));

    INSERT INTO @Progress VALUES (GETDATE(), N'A one');
    INSERT INTO @Progress VALUES (GETDATE(), N'And a two');

ROLLBACK

SELECT * FROM @Progress ORDER BY StatusDate;

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

Отладка SQL

Это полезно, когда вам нужно:

  • Отладить долго работающий процесс.
  • В процессе участвуют try/catch, begin/commit, в рамках которых что-то может упасть или откатиться.
  • Получить результат в табличной форме, возможно даже с несколькими колонками, XML, JSON, и т. д.

Так что вот они – 3 способа отладки без использования SSMS Debugger. Я обычно использую RAISERROR – это достаточно легко реализовать и этим механизмом будут пользоваться вечно. Конечно же, вариантов отладки гораздо больше.



Мне нравится 0   Мне не нравится 0



Комментарии

Чтобы добавить видео с YouTube, нужно написать [@youtube=xxxxx] , где xxxxx – ID видео.


Комментарии: 0
Нет ни одного комментария.
RSS-лента
Поделиться ссылкой:

Новое
C# и .NET: Blazor 3 дня назад, 09:00
C# и .NET: Blazor
Книги
Prometheus: Up & Running 2 дня назад, 10:03
Prometheus: Up & Running
Год: 2018
Visual Design of GraphQL Data Вт 12.03.2024
Visual Design of GraphQL Data
Год: 2018
Pro .NET Benchmarking Вт 05.03.2024
Pro .NET Benchmarking
Год: 2019
В работу с головой Вт 27.02.2024
В работу с головой
Год: 2017

Разработано на основе BlackNight CMS
Release v.2024-03-27
© 2000–2024 Blackball
Дизайн & программирование:
О сайтеРеклама
Visitors
Web-site performed by Sergey Drozdov
BlackballРекламаСтатистикаПоддержка | МузыкаПлейлистыКиноВидеоИгрыАудиоПрограммыСтатьиКартинкиЮморФорумДневник сайтаПрислать контент