Час очікування SQL Server з першої спроби

У мене виникає дивна проблема, коли я намагаюся приєднатися до SQL Server 2008, що працює на другому комп’ютері (обидві машини, на яких працює 64-розрядна версія Win7), або через джерела даних у Visual Studio, або через саму консоль управління SQL.

При першій спробі підключення він закінчується. Друга спроба працює чудово.

Я можу отримати доступ до спільних ресурсів на другому комп’ютері без будь-яких труднощів. Це якраз вперше намагаюся підключитися до SQL для кожного екземпляра програми. Тобто, якщо я відкрию два екземпляри Visual Studio, обидва вийдуть з ладу при першій спробі підключення, але вдасться у другій. Мені доводиться підключати двічі для кожного примірника (незалежно від послідовності відмов / успіху в будь-якій іншій програмі).

Сподіваюся, це має сенс.

Будь-яка порада?

Я думаю, що я знайшов рішення, принаймні в моєму випадку це працює. Я використовую ім'я екземпляра, і це автоматично передбачає динамічний порт для сервера sql. Я змінив налаштування з динамічного на порт виправлення, а потім відкрив брандмауер на цьому порту.

Менеджер конфігурацій SQL Server -> Конфігурація мережі SQL Server -> Протоколи для "InstanceName" -> TCP / IP -> Властивості -> Адреси IP -> IP All ->

Тут ви бачите два варіанти:

• Динамічні порти TCP: 51250 (генеровано випадковим чином)
• Порт TCP: порожній - я поставив сюди 1433, а потім відкрив брандмауер (на випадок, якщо він ще не був відкритий). Ви можете поставити потрібний порт (я поставив 1433, тому що це був єдиний екземпляр. У випадку декількох екземплярів слід вибрати для кожного примірника інший порт, а потім відкрити їх у брандмауері)

Сценарій, який використовується для полегшення вашого завдання відкрити порти, які я завантажив з MS, і відтворюю його тут (коментарі є німецькою мовою, але вони повинні бути очевидними):

@echo =========  Ports des SQL-Servers  ===================
@echo Aktivieren von Port 1433 für die SQLServer-Standardinstanz
netsh firewall set portopening TCP 1433 "SQLServer" 
@echo Aktivieren von Port 1434 für dedizierte Administratorverbindungen
netsh firewall set portopening TCP 1434 "SQL-Administratorverbindung" 
@echo Aktivieren von Port 4022 für den konventionellen SQL Server-Service Broker  
netsh firewall set portopening TCP 4022 "SQL-Service Broker" 
@echo Aktivieren von Port 135 für Transact-SQL-Debugger/RPC 
netsh firewall set portopening TCP 135 "SQL-Debugger/RPC" 
@echo =========  Ports für Analysedienste  ==============
@echo Aktivieren von Port 2383 für die SSAS-Standardinstanz
netsh firewall set portopening TCP 2383 "Analysedienste" 
@echo Aktivieren von Port 2382 für den SQL Server-Browserdienst
netsh firewall set portopening TCP 2382 "SQL-Browser" 
@echo =========  Verschiedene Anwendungen  ==============
@echo Aktivieren von Port 80 für HTTP 
netsh firewall set portopening TCP 80 "HTTP" 
@echo Aktivieren von Port 443 für SSL
netsh firewall set portopening TCP 443 "SSL" 
@echo Aktivieren des Ports für die Schaltfläche 'Durchsuchen' des SQL Server-Browserdiensts
netsh firewall set portopening UDP 1434 "SQL-Browser" 
@echo Zulassen von Multicast-/Broadcastantwort auf UDP (Aufzählung der Browserdienste OK)
netsh firewall set multicastbroadcastresponse ENABLE

Я найкраще думаю, що для бази даних увімкнено AUTO_CLOSE . Це означає, що при підключенні базу даних потрібно відкручувати, саме це спричиняє початковий тайм-аут.

Друга здогадка полягає в тому, що це може бути пов'язано з роздільною здатністю імені хоста. Таким чином, знадобиться занадто довго, щоб вперше вирішити ім'я хоста (можливо, шляхом трансляції?), Але потім кешується на наступні спроби з'єднання. Що ви використовуєте для вирішення хоста? це в DNS? Спробуйте змінити рядок з'єднання на формат IP, порт. тобто 192.168.100.100,1433

Ви також можете спробувати запуститись ipconfig /flushdnsпісля успішної спроби з’єднання та побачити, чи ви отримаєте таку ж поведінку. Невмілий спосіб вирішення полягає в тому, щоб помістити пошук у файл HOSTS, але ви повинні правильно його виправити.

Почувається, як довгий постріл у темряві, одягнений із зав'язаними очима, але це може допомогти. На форумах Microsoft SQL Developer є старовинна нитка, де описано, як виглядає та сама проблема, а також можливе виправлення. Його сервер працює під керуванням Windows Server 2008, але це може бути актуально і для налаштування Win7.

Нитка:

http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/58bd9c4d-0572-4567-8e32-82a7fd600022

З теми:

Так, я вирішив цю проблему.

Мій сервер Windows 2008 був сконфігурований для відхилення прив’язок SASL LDAP (див. Попередження 2886).

Оскільки я налаштував мій сервер не відхиляти такі прив’язки, підключення sql до сервера 2008 працюють правильно.

Ви можете ознайомитись з Microsoft KB 935834 для отримання інформації про зміну налаштувань підпису LDAP (не можу зв’язатись із цим, оскільки я новий користувач).

Сподіваюся, це допомагає!

Вимкнути брандмауер. Тестова мережа (ping). Відшукуйте мережевий трафік на sql-сервер (використовуйте дротяний сигнал )

Чи можете ви спробувати запустити SQL Profiler перед тим, як підключитися вперше з VS або SSMS, і подивитися, що відбувається на SQL сервері?

Крім того, чи перевірили ви журнали подій, щоб побачити, чи щось реєструється?