Nowo zainstalowany program SQL Server 2012. Nie utworzono jeszcze bazy danych. I mogę otworzyć Management Studio za pomocą sa / password. Binn \ sqlservr.exe jest uruchamiany jako usługa i widzę, że został uruchomiony na liście usług. Jednak nie nasłuchiwał portu 1433, a nawet domyślnie nie nasłuchiwał żadnego portu, jak sprawdziłem jak poniżej:

tasklist|find /I "sql"

Mam:

sqlservr.exe                  5668 Services                   0     40,112 K

w którym 5668 myślę, że to PID. A następnie, aby uzyskać PID = „5668” nasłuchuje, który port:

netstat -ano | find /I "5668"

ale nie mam nic prócz pustych. Z drugiej strony po przeszukaniu postów na tej stronie dwukrotnie sprawdziłem konfigurację mojego SQL Servera: start-> Wszystkie programy -> Microsoft SQL Server 2012 -> Narzędzia konfiguracyjne -> SQL Server Menedżer konfiguracji-> SQL Server SQL Native Client 11.0 Konfiguracja -> Protokoły klienta -> TCP / IP -> Domyślny port 1433. Istnieją 3 usługi, SQL Server (MyInstanceName), SQL Server Agent (MyInstanceName) i SQL Server Browser. Dwa ostatnie są zatrzymane.

Menedżer konfiguracji programu SQL Server-> Konfiguracja sieciowa programu SQL Server-> Protokoły dla MyInstanceName -> TCP / IP jest domyślnie wyłączony, po jego włączeniu i ponownym uruchomieniu usługi i powtórzeniu polecenia netstat -ano | polecenie find / I „newPIDNum” znalazłem

TCP    0.0.0.0:52395          0.0.0.0:0              LISTENING  5668(newPIDNum)   

Dlaczego 52395 zamiast 1433? I nie udało mi się utworzyć DSN przy użyciu systemu Windows ODBC Data Source administrator, który zwraca mi błąd: nie znaleziono określonego serwera SQL. Jakaś pomoc dla mnie? Dzięki.

To, co sprawiło, że mój serwer SQL nasłuchiwał TCPpołączeń na porcie 1433, to:

1. Narzędzia konfiguracyjne / Menedżer konfiguracji programu SQL Server
2. kliknij nazwę wystąpienia w SQL Server Network Configuration
3. umożliwić TCPkomunikację
4. Kliknij TCPwpis komunikacji prawym przyciskiem myszy , wybierzProperties
5. Kliknij kartę Adresy IP
6. Włącz wszystkie adresy IP inne niż VMnet i wpisz 1433 w polu Port„ IPAll ”.
7. Uruchom ponownie SQL Server na karcie Usługi SQL Server

8. Sprawdź swoją konfigurację za pomocą netstat -an:

   C:\>netstat -an | find "1433"
     TCP    0.0.0.0:1433           0.0.0.0:0              LISTENING
     TCP    [::]:1433              [::]:0                 LISTENING

Dlaczego 52395 zamiast 1433

Nazwane instancje nasłuchują na portach dynamicznych. Zadaniem Sql Server Browser Service jest informowanie klientów o rzeczywistym porcie. Przeglądarka Sql nasłuchuje na UDP 1434 i odpowiada na pytania typu „jaki jest port nasłuchujący instancji„ foo ”?”. Usługa Sql Server Browser jest wymagana zarówno dla protokołów TCP, jak i nazwanych potoków. Klienci używają SQL Server Browser w sposób transparentny, bez potrzeby specjalnej konfiguracji. Po prostu podając nazwę instancji w ciągu połączenia (lub ODBC DSN), biblioteka klientów wie, że musi najpierw skontaktować się z usługą SQL Server Browser.

Istnieją 3 usługi, SQL Server (MyInstanceName), SQL Server Agent (MyInstanceName) i SQL Server Browser. Dwa ostatnie są zatrzymane

Oczywiście, aby SQL Server Browser wykonał swoje zadanie, należy go uruchomić. Uruchom go i zmień typ uruchamiania na automatyczny.

Na marginesie, często używaną alternatywną konfiguracją jest użycie portów statycznych dla nazwanego wystąpienia i określenie portu w parametrze połączenia ( tcp:<hostname>:<port>). Ma tę zaletę, że usuwa SQL Server Browser z równania, ale wymaga starannej konserwacji klientów. Zmiana portu nasłuchiwania wymaga zaaranżowanych zmian na wszystkich klientach, wszystkich komputerach, we wszystkich lokalizacjach, zwykle duży ból. Polecam zamiast tego wziąć zależność od przeglądarki SQL Server.

Zapory ogniowe - 3 z nich

Ludzie, którzy nie są zaznajomieni z nowszymi wersjami systemu Windows (nie czuję się komfortowo z żadną po XP i próbowałem zainstalować SQL Server na Windows 10):

• Twoja zapora ogniowa musi być wyłączona w 3 oddzielnych miejscach (tj. Dla 3 różnych profili).

Jeśli zrobisz to tylko dla pierwszego, który zobaczysz (profil domeny), nadal będziesz się zastanawiać, dlaczego możesz połączyć się z portem 80 (IIS), ale nie z 1433 (SQL Server).

Nie mogę jeszcze komentować (niska reputacja, ponieważ mało aktywna): ale wyłączenie Zapory systemu Windows, jak wspomniano powyżej, jest najgorszą możliwą odpowiedzią. Prawidłowe byłoby: Utwórz reguły zapory w „przychodzącym”, aby umożliwić komunikację przez port 1433 na tych lokalnych adresach IP (lub wszystkich), których potrzebujesz. Polecam również ustawić, które zdalne adresy IP mogą łączyć się z tym serwerem SQL.