Комментарии 16
Поддерживаю вариант с табличными переменными, думаю это хорошоий выбор для задач отладки. Сейчас делаю систему отладки для бд оракл, там использую коллекции в пакете, что по смыслу похоже на табличную переменную из mssql. Может быть, найду время переписать ее и под mssql.
Для Oracle удобней журналирование в таблицу с автономными транзакциями, что позволяет оперативно контролировать ход выполнения в процессе длительных транзакций, не дожидаясь их завершения.
Да, в моей системе применяется и это.
Там предусмотрена возможность направить вывод отладочных процедур в консоль, в лог ( в автономной транзакции), и в кольцевой буфер, реализованный как динамическая именованная коллекция.
Разумеется все это с возможностью указать параметры сессии, которую собираемся отлаживать, и конечно же имеются фильтры для объектов программного кода и данных, которые в данный момент нас интересуют.
Довольно-таки большая система получилась, если организация даст добро, напишу подробно статью об этом.
А чем стандартный Oracle отладчик вас не устраивает? По-моему лучшего быть не может.
Есть целый рад случаев, когда отладчик не может заменить журналирование с расширенной диагностикой. Например, попробуйте отладчиком выявить код, приводящий к дидлокам.
В теории, отладчик хорош, если:
1 - у тебя есть права на отладку на этом сервере и
2 - ты заранее знаешь что именно собираешься отлаживать и
3 - есть возможность скомпилировать этот код, и
4 - можешь актуализировать данные по задаче ( все бизнес-обьекты и связанные справочники).
5 - полностью настроенно окружение сервера ( дблинки, шлюзы. и прочее)
На практике:
1 - нет прав отладки на проме ( и даже на тесте)
2 - неизвестно какой там сейчас код ( кто что намерджил, и что админы перенакатили в рамках инцидента).
3 - непредсказуемое поведение пользователя ( и тестировщика).
4 - состояние данных может существенно отличаться на серверах: проме, сервере разработки, и тестовом сервере. Синхронизация данных не всегда возможна.
5 - Среда окружения на разных серверах отличается (например: где-то подключены шлюзы к внешним системам, и есть дб-линки, а где-то нет)
Поэтому включаю режим отладки в приложении и на севере ( для сессии), и прошу тестировщика или пользователя воспроизвести действия, к которым имеются вопросы.
И еще такой момент:
Штатная система отладки предназначена для того, чтобы отвечать на вопрос "что произошло?". ( зашли в такую-то строку кода, присвоили такое-то значение переменной)
А на самом деле, нас интересует другой вопрос: "что делать?".
Самописная система, ориентрованная по такому принципу дает нам сразу готовый скрипт для воспроизведения ситуации (бага/инцидента), и готовые скрипты для некоторых других задач.
Поскольку она находится ближе к бизнес-обьектам и бизнес-процессам, то заодно дает ответ о текущем состоянии этих объектов и процессов, и дает рекомендации по исправлению ситуации.
SQL Server Management Studio тоже был отладчик кода, но, начиная с версии SSMS v18, он был удален
Но остался в "большой" Visual Studio, так что можно там походить по коду пошагово
https://www.youtube.com/watch?v=wng_eetygXM
Четвертый способ. Создаём таблицу журнала, какая нам нравится. Создаём локальный аккаунт, имеющий права только на вставку записей в эту таблицу журнала. Создаём linked server без DTC на самого себя с этим аккаунтом. Все сообщения пишем через linked server в таблицу журнала. Получаем не только оперативный доступ к сообщениям во время выполнения транзакции, но ещё и удобное средство диагностики, если запись сообщений в журнал кофигурируема (trace, debug, info, etc).
В Oracle для таких целей есть автономные транзакции, которых в MS SQL и PostgreSQL пока нет. Для последнего вместо linked server - dblink
Надо ли чистить код отладки, когда закончил её и убедился, что всё работает?
Про первый способ понятно, но про остальные хотелось бы получше понять, как это на производительность влияет
Raiserror самый тяжёлый. Но если речь о запросах, которые выполняются хотя бы секунду, то те 20-30 мс, которые на raiserror расходуются, составят 2-3 процента. А если, как у ТС, речь идёт о запросах, выполняющихся минуты, то издержки точно окажутся у пределах статистической погрешности.
К тому же никто не запрещает уровень диагностики конфигурировать (trace, debug, info, warning ...). На зоне разработки пусть будет debug или trace. На продуктиве - warning или info.
Думаю, что если под отладой будет находиться одна отдельно взятая сессия ограниченное количество времени, то это не существенное влияние на сервер. (если есть понимание обьемов данных в задаче и количества вызовов, и не выходить за пределы разумного)
Более того, в некоторых организациях есть и отдельный сервер для подобных задач - полная копия прома с данными и программными обьектами.
Другой вопрос какова цена присутствия на проме в программном коде процедур отладки даже в выключенном состоянии ( включаемых по мере необходимости). Это тема для отдельного разговора, надо смотреть по ситуации.
4-й способ - раскошеливаемся на dbForge.
Три способа отладки T-SQL кода