Я нещодавно встановив SQL Server 2012. Ще не створено базу даних. І я можу відкрити студію управління за допомогою sa / password. Binn \ sqlservr.exe запускається як послуга, і я бачу, як він почався у списку послуг. Однак він не прослуховував порт 1433 або навіть, не слухав жоден порт за замовчуванням, як я перевірив, як показано нижче:

tasklist|find /I "sql"

Я зрозумів, я отримав:

sqlservr.exe                  5668 Services                   0     40,112 K

в якому 5668, я думаю, є ПІД. А потім отримати PID = "5668" прослуховує, який порт:

netstat -ano | find /I "5668"

але я нічого не маю, крім порожнього. З іншого боку, після пошуку публікацій на цьому веб-сайті я ще раз перевірив конфігурацію свого SQL Server: пуск-> Усі програми -> Microsoft SQL Server 2012 -> Інструменти конфігурації -> Менеджер конфігурацій SQL Server-> SQL Server SQL Native Client 11.0 Конфігурація -> Клієнтські протоколи -> TCP / IP -> Порт за замовчуванням 1433. Є 3 сервіси, SQL Server (MyInstanceName), агент SQL Server (MyInstanceName) та браузер SQL Server. Останні два зупинені.

Менеджер конфігурацій SQL Server-> Конфігурація мережі SQL Server-> Протоколи для MyInstanceName -> TCP / IP відключений за замовчуванням, після того як я ввімкнув його та перезапустив службу та повторив netstat -ano | Знайти / Я "newPIDNum" команду Я знайшов

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

Чому 52395 замість 1433? І мені не вдалося створити DSN за допомогою адміністратора джерела даних ODBC Windows, який повертає мені помилку: вказаний сервер SQL не знайдений. Будь-яка допомога для мене? Дякую.

Що змусило мій SQL-сервер слухати TCPз'єднання на порту 1433:

1. Інструменти конфігурації / Менеджер конфігурацій SQL Server
2. натисніть ім'я екземпляра в мережевій конфігурації SQL Server
3. дозволяють TCPспілкуватися
4. Клацніть правою кнопкою миші TCPзапис зв'язку, виберітьProperties
5. Перейдіть на вкладку IP-адреси
6. Увімкніть усі IP-адреси, що не VMnet, і введіть 1433 у Portзапис для " IPAll ".
7. Перезавантажте SQL Server на вкладці Служби SQL Server

8. Перевірте конфігурацію за допомогою netstat -an:

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

Чому 52395 замість 1433 року

Названі екземпляри слухають на динамічних портах. Це завдання браузера Sql Server, щоб повідомити клієнтів про фактичний порт. Браузер Sql прослуховує UDP 1434 і відповідає на запитання форми "що таке порт прослуховування екземпляра" foo "?". Послуга браузера Sql Server потрібна як для протоколів TCP, так і для іменованих труб. Клієнти користуються браузером SQL Server прозоро, не потрібно спеціальної конфігурації. Просто вказавши ім'я екземпляра в рядку з'єднання (або ODBC DSN), бібліотека клієнтів знає, що він повинен спочатку звернутися до служби браузера SQL Server.

Є 3 сервіси, SQL Server (MyInstanceName), агент SQL Server (MyInstanceName) та браузер SQL Server. Останні два зупинені

Очевидно, щоб браузер SQL Server виконував свою роботу, його потрібно запустити. Запустіть його та змініть тип запуску на автоматичний.

Як бічна примітка, часто застосовується альтернативна конфігурація - використовувати статичні порти для названого екземпляра та вказати порт у рядку з'єднання ( tcp:<hostname>:<port>). Він має перевагу у виведенні браузера SQL Server із рівняння, але він вимагає ретельного обслуговування клієнтів. Зміна порту прослуховування вимагає організованих змін у всіх клієнтів, на всіх машинах, у всіх місцях, як правило, великий біль. Я рекомендую замість цього взяти залежність від браузера SQL Server.

Брандмауери - їх 3

Люди, які не знайомі з більш новими версіями Windows (мені не подобається жодна після XP, і намагалися встановити SQL Server на Windows 10):

• Ваш брандмауер повинен бути встановлений у 3 окремих місцях (тобто для 3 різних профілів).

Якщо ви зробите це лише для першого, який ви бачите (профіль домену), вам все одно залишатиметься питанням, чому ви можете підключитися до порту 80 (IIS), а не 1433 (SQL Server).

Я поки не можу коментувати (низька репутація, оскільки не дуже активна): але відключення брандмауера Windows, як це було сказано вище, є найгіршою можливою відповіддю. Правильним було б: Створіть правила брандмауера у режимі "вхідний", щоб дозволити порту 1433 спілкуватися на тих локальних IP-адресах (або всіх), які вам потрібні. А також я рекомендую встановити, які віддалені IP-адреси дозволено підключати до цього SQL-сервера.