MSSQL Периодическая ошибка TCP-соединения при высокочастотных запросах к связанному серверу (связан с пулом соединений?)

У меня есть четыре задания агента SQL, которые работают непрерывно. Каждое задание выполняет хранимую процедуру, которая запрашивает последние транзакции банкомата, все через один и тот же связанный сервер. Это происходит в цикле внутри каждого задания с 5-секундной задержкой между выполнением процедуры (с использованием WAITFOR DELAY).

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

В большинстве случаев все работает нормально. Но иногда (почти *) любое из заданий завершается с этой ошибкой:

Поставщик TCP: указанное сетевое имя больше не доступно. [SQLSTATE 42000] (Ошибка 64) Поставщик OLE DB "SQLNCLI11" для связанного сервера "ATMDB" возвратил сообщение "Сбой канала связи". [SQLSTATE 01000] (ошибка 7412).

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

Нет никакой последовательности в том, как часто они будут терпеть неудачу, но это по крайней мере несколько раз в день.

* Я говорю "почти" выше, потому что одно из заданий никогда не подводило. Это тот, который чаще всего получает "попадания", и когда это происходит, этапу работы разрешается завершать, поэтому у нас есть явная регистрация этого в журналах заданий SQL. (Затем он возвращается к первому шагу снова через 1 секунду.)

Все задания настроены для запуска каждую минуту. Таким образом, после сбоя работа будет возобновлена ​​в начале следующей минуты, поэтому это не сильно влияет на ситуацию. Это просто очень раздражает!

Я подозреваю, что коренной проблемой является собственный клиент SQL и то, как он реализует пул соединений. Во время тестирования я обновил связанный сервер в одной из двух процедур, чтобы она отличалась от другой. Два разных имени хоста, но на самом деле все тот же сервер (я просто использовал файл hosts для создания нового имени). Это приводило к тому, что одно задание больше не выходило из строя, но два из трех других заданий все равно периодически терпели неудачу. После переключения другой процедуры на использование того же связанного сервера снова, теперь все задания снова будут иногда прерываться. Поскольку пулы соединений относятся к строке соединения, другое имя сервера может привести к использованию другого пула.

Используя монитор ресурсов Windows, я вижу, что к связанному серверу обычно открыто три TCP-соединения. Они остаются открытыми на одних и тех же портах в течение нескольких минут, поэтому я предполагаю, что он использует какой-то пул соединений. Когда происходит ошибка, она совпадает с одним из закрытых соединений и вскоре после открытия нового соединения.

Моя текущая теория: поскольку при использовании связанного сервера процессы циклически повторяются, что-то в пуле соединений вызывает ситуацию, когда он пытается использовать соединение, которое было закрыто по какой-либо причине. Возможно, один шаг задания, который "завершает" время от времени, каким-то образом обновляется и предотвращает возникновение ошибки в этом конкретном процессе.

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

Оба сервера - Windows 2012, работающие в VMWare.

Любые идеи о том, как дальнейшее устранение неполадок?