Limit czasu serwera SQL przy pierwszej próbie

Mam dziwny problem polegający na tym, że próbuję dołączyć do programu SQL Server 2008 uruchomionego na drugim komputerze (oba komputery z systemem Windows 7 w wersji 64-bitowej), albo poprzez źródła danych w Visual Studio, albo przez samą konsolę zarządzania SQL.

Przy pierwszej próbie połączenia upłynął limit czasu. Druga próba działa dobrze.

Mogę uzyskać dostęp do udziałów na drugim komputerze bez żadnych trudności, wygląda na to, że po raz pierwszy próbuję połączyć się z SQL dla każdej instancji aplikacji. Oznacza to, że jeśli otworzę dwie instancje Visual Studio, obie zakończą się niepowodzeniem przy pierwszej próbie połączenia, ale powiodą się przy drugiej. Muszę połączyć się dwukrotnie dla każdej instancji (niezależnie od sekwencji błędów / sukcesów w dowolnej innej aplikacji).

Mam nadzieję, że to ma sens.

Jakakolwiek rada?

Myślę, że znalazłem rozwiązanie, przynajmniej w moim przypadku działa. Używam nazwy instancji, a to automatycznie oznacza dynamiczny port dla usługi serwera SQL. Zmieniłem ustawienia z dynamicznego na stały port, a następnie otworzyłem zaporę na tym porcie.

Menedżer konfiguracji programu SQL Server -> Konfiguracja sieci programu SQL Server -> Protokoły dla „InstanceName” -> TCP / IP -> Właściwości -> Adresy IP -> Wszystkie IP ->

Tutaj widzisz dwie opcje:

• Dynamiczne porty TCP: 51250 (generowane losowo)
• Port TCP: pusty - wstawiłem tutaj 1433, a następnie otworzyłem zaporę ogniową (na wypadek, gdyby nie była jeszcze otwarta). Możesz ustawić dowolny port (wstawiłem 1433, ponieważ był to jedyny przypadek. W przypadku wielu wystąpień należy wybrać dla każdego wystąpienia inny port, a następnie otworzyć je w zaporze)

Skrypt ułatwiający otwieranie portów pobranych z MS i odtwarzam go tutaj (komentarze są w języku niemieckim, ale powinny być oczywiste):

@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

Moim zdaniem przypuszczam, że masz włączone AUTO_CLOSE dla bazy danych. Oznacza to, że baza danych musi się rozproszyć podczas łączenia, co powoduje początkowy limit czasu.

Po drugie, może to być związane z rozpoznawaniem nazw hostów. Dlatego zbyt długo trwa rozpoznawanie nazwy hosta (może przez transmisję?), Ale potem jest buforowana przy kolejnych próbach połączenia. Czego używasz do rozwiązania hosta? czy to jest w DNS? Spróbuj zmienić ciąg połączenia, aby był w formacie portu IP. tj. 192.168.100.100,1433

Możesz także spróbować uruchomić ipconfig /flushdnspo udanej próbie połączenia i sprawdzić, czy uzyskasz takie samo zachowanie. Nieostrożne obejście polega na umieszczeniu odnośnika w pliku HOSTS, ale należy go poprawnie naprawić.

Wygląda jak długi strzał w ciemność z opaską na oczy, ale może pomóc. Na forach Microsoft SQL Developer znajduje się stary wątek opisujący, co wydaje się być tym samym problemem, wraz z możliwą poprawką. Na jego serwerze działa system Windows Server 2008, ale może być również odpowiedni dla konfiguracji Win7.

Groźba:

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

Z wątku:

Tak, naprawiłem ten problem.

Mój Windows Server 2008 został skonfigurowany do odrzucania powiązań SASL LDAP (patrz ostrzeżenie 2886).

Ponieważ skonfigurowałem mój serwer, aby nie odrzucał takich powiązań, połączenia SQL Server 2008 działają poprawnie.

Informacje na temat modyfikowania ustawień podpisywania LDAP można znaleźć w Microsoft KB 935834 (nie mogę się z tym połączyć, ponieważ jestem nowym użytkownikiem).

Mam nadzieję, że to pomoże!

Wyłącz zaporę ogniową. Testuj sieć (ping). Sniff ruch sieciowy do serwera SQL (użyj Wireshark )

Czy możesz spróbować uruchomić SQL Profiler przed pierwszym połączeniem z VS lub SSMS i zobaczyć, co się dzieje na SQL Server?

Czy sprawdziłeś także dzienniki zdarzeń, aby sprawdzić, czy coś jest rejestrowane?