Как начать диагностику периодических ошибок подключения к SQL Server?

На самом деле у нас была похожая ситуация с приложением Python, использующим драйвер pymssql. Нашим конкретным сообщением было «неожиданный EOF». Мы так и не догадались. Мы только что реализовали повторную попытку на стороне клиента ...

Мы перепробовали множество вещей. В рамках обычного мониторинга мы отслеживаем количество активных TCP-соединений. Возможно, они превышали максимум SQL Server? Но все было хорошо.

Наконец, мы запустили tcpdump чтобы захватить весь трафик, чтобы мы могли просматривать его в Wireshark. Установите его для отображения времени UTC, чтобы вы могли сопоставить записи журнала. Возможно также зарегистрировать возвращаемый TCP-порт этого конкретного соединения или другую идентифицируемую информацию.

Мы обнаружили, что сервер иногда отправляет FIN (finish) сразу после сообщения перед входом в систему TDS. Нет никаких веских причин. Максимальное количество подключений далеко не достигается.

Думаю, в вашем случае я бы:

• Проделайте трюк с tcpdump
• Напишите тестовый сценарий или небольшое приложение, которое подключается каждую минуту, и посмотрите, сможете ли вы воспроизвести его таким образом.
• Если вы можете воспроизвести это таким образом, также посмотрите, попробуете ли вы простое TCP-соединение с этим портом, и это тоже не сработает. Поскольку ваша ошибка: «Сетевой путь не найден», это может быть действительно так.

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

Вот вопросы, которые я задаю, чтобы разобраться в основной причине:

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

Это случается со всеми серверами приложений? Если у вас несколько приложений или веб-серверов, затронуты ли они все? (Если у вас только один, сейчас отличное время, чтобы настроить другой для устранения неполадок и сбалансировать нагрузку между ними.)

Затронуты ли все запросы в приложении или только некоторые? Иногда я вижу, что долго выполняющиеся запросы продолжают выполняться, но затрагиваются только новые соединения.

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

Есть ли закономерность в днях / времени тайм-аутов? Начните записывать их или документировать, когда они случаются. Например, в одном случае мы увидели, что дни / время точно коррелировали с регулярно запланированными проверками портов командой безопасности.

Может ли сервер приложений во время тайм-аутов проверять связь с SQL Server?Когда все остальное не помогло с одной процедурой устранения неполадок, мы помещаем бесплатный инструмент сетевого мониторинга на сервер приложений для проверки связи с SQL Server каждые 10 секунд. Разумеется, в следующий раз, когда у приложения были тайм-ауты запроса, мы смогли доказать, что даже пинги не работают, тем самым исключив проблему SQL.

Задайте эти вопросы, и иногда вам даже не нужно устранять неполадки SQL Server - ответы рассказывают всю историю.

Используйте TCP вместо именованных каналов.

Используйте эти инструкции в качестве руководства для отключения именованных каналов: https://www.blackbaud.com/files/support/infinityinstaller/content/installermaster/tkenable namedpipesandtcpipconnections.htm