Visual Studio의 데이터 소스 또는 SQL 관리 콘솔 자체를 통해 두 번째 컴퓨터(두 컴퓨터 모두 Win7 64비트를 실행하는 컴퓨터)에서 실행 중인 SQL Server 2008에 연결하려고 할 때 이상한 문제가 발생했습니다.
처음 연결을 시도하면 시간이 초과됩니다. 두 번째 시도는 잘 작동합니다.
두 번째 컴퓨터에서는 아무런 어려움 없이 공유에 액세스할 수 있는데, 각 애플리케이션 인스턴스에 대해 SQL에 연결을 시도한 것은 이번이 처음인 것 같습니다. 즉, 두 개의 Visual Studio 인스턴스를 열면 두 인스턴스 모두 첫 번째 연결 시도에서는 실패하지만 두 번째 연결에서는 성공합니다. 다른 애플리케이션의 실패/성공 순서에 관계없이 각 인스턴스에 대해 두 번 연결해야 합니다.
그게 말이 되기를 바랍니다.
어떤 충고?
답변1
나는 해결책을 찾았다고 생각합니다. 적어도 제 경우에는 효과가 있습니다. 인스턴스 이름을 사용하고 있으며 이는 자동으로 SQL Server 서비스에 대한 동적 포트를 의미합니다. 설정을 동적에서 수정 포트로 변경한 다음 해당 포트에서 방화벽을 열었습니다.
SQL Server 구성 관리자 --> SQL Server 네트워크 구성 --> 'InstanceName'에 대한 프로토콜 --> TCP/IP --> 속성 --> IP 주소 --> IP 모두 -->
여기에는 두 가지 옵션이 있습니다.
- 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
답변2
내 최선의 추측은 당신이AUTO_CLOSE데이터베이스에 대해 켜졌습니다. 즉, 연결할 때 데이터베이스를 스핀업해야 하며 이로 인해 초기 시간 초과가 발생합니다.
두 번째 추측은 호스트 이름 확인과 관련이 있을 수 있다는 것입니다. 따라서 처음에 호스트 이름을 확인하는 데 시간이 너무 오래 걸리지만(아마 브로드캐스트로?) 이후 연결 시도 시 캐시됩니다. 호스트를 해결하기 위해 무엇을 사용하고 있습니까? DNS에 있나요? 연결 문자열을 IP, 포트 형식으로 변경해 보세요. 즉 192.168.100.100,1433
연결 시도가 성공한 후 실행을 시도하여 ipconfig /flushdns동일한 동작이 나타나는지 확인할 수도 있습니다. 이상한 해결 방법은 HOSTS 파일에 조회를 넣는 것이지만 올바르게 수정해야 합니다.
답변3
눈가리개를 쓰고 어둠 속에서 먼 길을 가는 것처럼 느껴지지만 도움이 될 수도 있습니다. Microsoft SQL 개발자 포럼에는 가능한 수정 사항과 함께 동일한 문제로 보이는 것을 설명하는 오래된 스레드가 있습니다. 그의 서버는 Windows Server 2008을 실행하고 있지만 Win7 설정에도 관련이 있을 수 있습니다.
스레드:
스레드에서:
예, 이 문제를 해결했습니다.
내 Windows Server 2008은 SASL LDAP 바인딩을 거부하도록 구성되었습니다(경고 2886 참조).
이러한 바인딩을 거부하지 않도록 서버를 구성했기 때문에 SQL Server 2008 연결이 올바르게 작동합니다.
LDAP 서명 설정 수정에 대한 정보는 Microsoft KB 935834를 참조하세요(새로운 사용자이기 때문에 링크할 수 없음).
도움이 되길 바랍니다!
답변4
VS 또는 SSMS에 처음 연결하기 전에 SQL 프로파일러를 실행해보고 SQL Server에서 무슨 일이 일어나고 있는지 확인할 수 있습니까?
또한 이벤트 로그를 확인하여 기록되는 항목이 있는지 확인했습니까?