Начальное соединение с SQL Server. Соединение медленное. Зачем? - PullRequest
Новая
       32

Начальное соединение с SQL Server. Соединение медленное. Зачем?

12 голосов
/ 24 ноября 2010

Я столкнулся с ситуацией с приложением C #, установленным на двух сайтах, где первоначальное соединение с SQL Server очень медленное. Я написал тестовое приложение, чтобы проверить, где происходит замедление, и оно находится в первом операторе SQLConnection.Open. Установление соединения с сервером через именованные каналы заняло около 41 секунды. Мы подумали, что это может быть проблема DNS, но она так же медленна при использовании соединения TCP / IP. После того, как начальное соединение установлено, соединение объединяется, и приложение отвечает нормально. И рабочая станция, и сервер являются приличными компьютерами под управлением Windows 7 Pro, Core 2 Duo 3.16 ГГц с 4 гигабайтами Ram. Я нашел следующую статью на форуме Microsoft:

http://social.msdn.microsoft.com/Forums/en/windowscompatibility/thread/f295994c-5812-4e46-8ac9-f05471d4dd54

При отключении протокола LLMNR начальное время соединения сократилось примерно на половину до 21 секунды. Тем не менее, это все еще долго, чтобы получить первоначальное подключение к SQL Server. Единственное, что немного отличается от нашей нормы, это то, что DNS в этом случае выполняется через маршрутизатор, а не реальный сервер. Пока что это произошло только в двух местах, другие работают без проблем. Любая помощь будет оценена.

Спасибо, Dennis

Ответы [ 14 ]

8 голосов
/ 09 апреля 2014

Перед сервером в строке подключения добавьте np:

Это становится Server=np:server\instance и вызывает именованные каналы вместо TCP по умолчанию.

Возможно, я мог изменить приоритет использования именованных каналов перед TCP ... но я не хотел связываться с этим на сервере.

5 голосов
/ 19 декабря 2010

Я видел похожую проблему, но не уверен, что она такая же, как у вас.В моем случае не только программа на C # медленно устанавливает соединение SQL.Это любые инструменты, подключающиеся к SQL-серверу, также испытывающие медлительность.Кроме того, после первоначального подключения к серверу SQL все последующие подключения будут работать в течение определенного периода времени.

Причина в том, что сервер SQL использовал несколько управляемых сборок.Он пытается проверить сертификаты, присвоенные сборкам.Это соединяет crl.microsoft.com.Мой SQL-сервер не имел подключения к интернету.Итак, он ожидает тайм-аута.

Решение состояло в том, чтобы заставить мой SQL-сервер иметь доступ в Интернет или отключить проверку CRL.Вы можете перейти на компьютер с сервером SQL.Выберите «Инструменты»> «Свойства обозревателя»> «Дополнительно».Проверьте, проверяется ли отзыв сертификата издателя под узлом безопасности или нет.Если флажок установлен, снимите флажок.

4 голосов
/ 30 ноября 2010

Я попытался указать строку подключения с интегрированной защитой = false (это означает, что идентификатор пользователя и пароль находятся в строке подключения) и encrypt = false (просто будьте на 100% уверены, что шифрование SSL не используется). Эти спецификации, похоже, не помогли, и я не смог установить соединение явно, используя сетевую библиотеку TCP / IP (NetworkLibrary = "dbmssocn"). Это может быть связано с тем, что межсетевой экран сервера и порт не открыты. Я переключился обратно на именованные каналы и на этот раз поместил спецификацию сетевой библиотеки именованных каналов в строку подключения (NetworkLibrary = "dbnmpntw"). После этого изменения соединение было установлено мгновенно.

1 голос
/ 25 июля 2018

Установление интегрированного безопасного соединения с SQL Server с использованием IP-адреса (вместо имени хоста) предотвратит использование аутентификации Kerberos.В этом случае проверьте соединение между SQL Server и контроллером домена.

Если вы подключаетесь, используя имя хоста (не IP-адрес), Kerbos работает, в этом случае вам необходимо проверить подключение клиентского компьютера к контроллеру домена.

1 голос
/ 18 апреля 2014

Вы проверили очевидное, я так понимаю? Этот UDP-порт 1434 открыт на брандмауэре, и служба браузера работает .... Для аутентификации в противном случае потребуется около 40 секунд.

1 голос
/ 19 декабря 2010

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

Кроме того, когда SQL Server не используется в течение длительного периода времени, он ведет себя подобно IIS, переводя рабочий процесс в спящий режим, поэтому при повторном обращении к серверу, в зависимости от компьютера (мы видим, конфигурации настольных компьютеров), потребуется некоторое время, пока рабочий процесс вернется к жизни и будет готов к работе.

0 голосов
/ 17 января 2018

В моем случае ответ был:

  • Попробуйте все безрезультатно.
  • Удаленный рабочий стол на (non-prod) SQL Server для двойной проверки настроек.
  • Закройте Visual Studio, которую вы оставили, выполнив быструю работу SSIS.
  • Отправляйтесь в тихое место и пинайте себя.
0 голосов
/ 15 октября 2016

У меня была такая же проблема. После тщательного изучения google и stackoverflow я изменил файл hosts на клиентском компьютере (в windows, расположенном по адресу C: \ Windows \ System32 \ drivers \ etc). В этом файле я ввел ip-адрес своего хоста и имя сервера и Viola! Все стало очень быстро! Как говорили все в stackoverflow, это был компьютер, который просматривал адрес сервера в DNS-службе и получал тайм-аут. Выполните следующие действия. Попробуйте, если ничего не работает.

КАК ДОБАВИТЬ ЗАПИСЬ В ФАЙЛ ХОСТОВ

1.Откройте командную строку и проверьте связь с сервером, на котором расположена удаленная база данных. Для этого введите следующую команду: 

ping servername

Здесь имя моего удаленного компьютера было Juno. Так что я должен пинговать так. 

ping Juno

Эта команда пингует мой сервер и возвращает IP-адрес следующим образом. 

Pinging Juno [192.168.0.3] with 32 bytes of data:

Как видите, IP-адрес сервера находится в скобках. Скопируйте IP-адрес.

2. Теперь откройте файл Hosts с помощью Блокнота с повышенными правами (Запуск от имени администратора).

В конце файла hosts появятся следующие строки: 

    #localhost name resolution is handled within DNS itself.
    #   127.0.0.1       localhost
    #   ::1             localhost

В самом низу (здесь, после localhost) введите # и введите IP-адрес сервера, который мы только что получили, перед именем сервера. Итак, файл hosts должен выглядеть следующим образом. 

# localhost name resolution is handled within DNS itself.
#   127.0.0.1       localhost
#   ::1             localhost
#   169.254.63.1    Juno
  1. Теперь сохраните файл hosts и перезагрузите клиентский ПК. (Для меня это работало мгновенно без перезапуска.)

И вот, пожалуйста!

Для получения дополнительной информации о редактировании файла hosts нажмите здесь

0 голосов
/ 13 февраля 2012

Тем не менее, если вы столкнулись с проблемой, см. Разрешение удара:

Основная причина

Проблема, с которой мы столкнулись в Win7 VDI, может быть связана с сетевым устройством, подключенным к машине. Если сетевое устройство не поддерживает масштабирование TCP / IP, производительность будет низкой.

Решение

Отключить автонастройку уровня TCP. Пожалуйста, следуйте ниже шагов: 1) Открыть командную строку с правами администратора (Запуск от имени администратора) 2) Введите «netsh interface tcp set global autotuninglevel = отключено» 3) После выполнения вышеуказанной команды перезапустите машину.

Для получения дополнительной информации об этой команде посетите ссылку «http://support.microsoft.com/kb/935400”

0 голосов
/ 17 декабря 2010

У нас была та же проблема, и оказалось, что виноват наш удаленный сервер Active Directory.

Мы создали локальный сервер Active Directory для репликации удаленного хоста AD, а затем все наши проблемы с медленной производительностью аутентификации интегрированной безопасности SQL Server исчезли.

Надеюсь, это поможет.

Страница:
...