У меня есть веб-сервер (собственный клиент IIS7 / .NET 3.5), подключающийся к SQL 2005 через брандмауэр.
Сервер находится в кластере с именованным экземпляром, настроенным для ответа на статический порт 1089.
TCP-порты 1433 и 1089 открыты на брандмауэре, UDP-порт 1434 также открыт.
После установления соединения установка выполняется очень быстро (~ 10 мсек на запрос), однако установка первого соединения занимает 37 секунд!
Используемая строка подключения следующая:
Источник данных = 1.2.3.4,1098; Сетевая библиотека = DBMSSOCN; Начальный каталог = MyDatabase; идентификатор пользователя = my_user_id; пароль = secret_stuff
Веб-сервер и sql-сервер находятся в разных доменах. Однако я использую проверку подлинности SQL.
Если я подключаюсь с обычной клиентской машины, все работает как шарм.
Кто-нибудь раньше сталкивался с этой проблемой? Как я могу решить эту проблему или хотя бы изучить проблему дальше?
В вопросе вы сказали: «Я использую аутентификацию SQL», однако, если сервер настроен так, чтобы разрешить как интегрированную, так и аутентификацию SQL, он может пытаться выполнить поиск домена.
Проверьте средство просмотра событий безопасности на сервере и найдите события сбоя для аутентификации.
Похоже, что по какой-то причине он пытается сделать обратный DNS на адресе 1.2.3.4, возможно, это настройка IIS, но это может быть что-то еще. Если вы добавите запись хостов в c:\windows\system32\drivers\etc\hosts для имени сервера SQL имеет значение?
Если это не помогает или вы просто хотите понять, что вообще происходит в подобных ситуациях, вам следует использовать анализатор сетей \ пакетов. Сетевой монитор Windows или WireShark оба сделают трюк в вашем случае. Это нетривиальные инструменты для использования, но если вы зафиксируете сеанс, который демонстрирует вашу проблему, вы сможете увидеть, какой трафик непосредственно предшествует длительной задержке, и, если повезет, сможете сосредоточиться на основной причине.