Это призыв к суду. Я бы сказал, что наиболее определяющим фактором является то, как долго сокет остается открытым. Если он имеет «транзакционную» длину, которая сильно варьируется от системы к системе - тогда я бы сказал, что это нормально. Я не вижу проблем с кластеризацией, так как SQL Server не имеет активных / активных кластеров (но это, безусловно, было бы возможно с NLB). Другим определяющим фактором будет то, является ли сокет единичным экземпляром (прослушивающим не широковещательный порт).
Итак, да, если:
- Функция / хранимая процедура должна вызываться из T-SQL (агент SQL Server или SSRS?)
- Ожидается, что функция / хранимая процедура завершится в течение периода времени «транзакции»
(Я бы сказал, что 30 секунд - это типично, но в высоконагруженной системе вызов, который блокируется, а затем ждет 30 секунд, может быть чреват, поэтому вам нужно будет рассмотреть ваш вариант использования.)
- Функция реентерабельна (может запускаться несколько раз параллельно)
Нет, если:
- Функция вызывается из C # или другого более способного клиента (ваша обработка там - возможно, из библиотеки?)
- Функция будет ожидать неопределенное количество времени, намного превышающее типичную длину транзакции
- Функция является единичным экземпляром (только один сеанс сможет успешно выполнить функцию)
Рассмотрим несколько примеров, иллюстрирующих разницу:
Задание агента SQL Server, которое ежедневно заполняет таблицу диаграммой тарифов, соскребенной с мэйнфрейма.
Установлена функция CLR, которая принимает документ соскребания XML, подключается к мэйнфрейму и использует экранное скрепление TN 3270 для возврата набора результатов в форме, указанной в документе XML
- Должен вызываться из SQL (для простоты обслуживания и создания отчетов об ошибках)
- Должно ли превышаться время ожидания, если оно превышает установленное время ожидания (~ 30 с)
- Может быть запущен в нескольких сеансах параллельно
- Ответ: Хороший кандидат на функцию SQL CLR
Приложение "Ticker", в котором приложение прослушивает UDP-трансляции обновлений цен и возвращает клиенту набор результатов в виде потокового набора результатов
Функция CLR открывает порт прослушивания широковещательной передачи UDP и асинхронно записывает результаты обратно клиенту. Это продолжается до тех пор, пока не будет достигнуто конечное условие, определенное приложением (конкретная полезная нагрузка пакета, отмена запроса или время ожидания)
- Должен вызываться из SQL для обработки множества платформ (некоторые клиенты на PHP на Linux, другие на VB6 на Windows)
- Имеет определенное и контролируемое пользователем время ожидания (но частично не проходит этот тест, так как оно, вероятно, превысит продолжительность транзакции).
- Может работать в нескольких сеансах параллельно (широковещательно)
- Ответ: «Хорошо» кандидат для функции SQL CLR
Сервер системного журнала, который сбрасывает полученные события в таблицу
Функция, которая открывает прослушиватель UDP на 0.0.0.0:514 и возвращает события в виде потокового набора результатов.
- Нет реальной причины, по которой он должен вызываться из SQL, поскольку он буферизуется в таблицу независимо от
- Не имеет времени ожидания - ожидается запуск 24/7
- Вызывающее приложение (агент SQL Server) должно убедиться, что эта функция всегда выполняется ровно один раз, и перезапустить ее в случае сбоя (повторная реализация диспетчера служб)
- Ответ: Не подходит для SQL CLR, рассмотрите Service Broker + NT Service