Почему я могу подключиться к экземпляру SQL Server 2005, используя sqlcmd, но не SSMS после изменения IP-адреса?

Question

У нас есть несколько экземпляров SQL Server в нашем главном офисе и один на нашем совместном веб-сервере. Существует несколько репликаций, которые обеспечивают обмен данными между веб-сервером и серверами главного офиса.

Мы поменяли интернет-провайдеров сегодня в нашем главном офисе. Мы выполнили домашнюю работу и были готовы к переключению (изменения ips в файлах хостов и т. Д.). Как только мы переключились на новое соединение, все репликации полностью прервались. Я пытался подключиться к серверам нашего основного офиса, используя SSMS; без печенья. Мы можем нормально пропинговать и ftp к серверам нашего домашнего офиса, используя имена серверов с нашего веб-сервера. Я увидел, что порты 1433 и 1434 были заблокированы новым провайдером, и уведомил соответствующих людей; они должны быть разблокированы сейчас. Все еще нет кости от SMSS.

Затем я попытался соединиться с sqlcmd, который работал потрясающе. SMSS не будет подключаться к серверу, но sqlcmd будет. Почему это? До переключения ISP все работало как прелесть.

Пример

ping homeserver
    success!
ftp homeserver
    success!
sqlcmd -S homeserver\instance -U user -P pass
    success!
- Trying to connect using SSMS, using the same homeserver\instance and user/pass combo
    Provider: SQL Network Interfaces, error: 26 - Error locating server/instance specified) 

Answer 1

SQL Не прослушивает TCP 1434, он прослушивает UDP 1434. Вы не можете тестировать порты UDP, используя telnet. Ваш провайдер должен открыть UDP 1434.

Проверьте порядок подключения клиента на сервере, и я пойму, что Именованные каналы выше TCP / IP, но SSMS по какой-то причине не использует Именованные каналы.

Если вы используете именованные экземпляры, убедитесь, что у SQL Server есть все открытые порты TCP между colo и офисом.

Возможно, вы захотите настроить VPN между офисом и администрацией, чтобы вам не приходилось беспокоиться о брандмауэрах между ними.

Answer 2

Немного догадываюсь, но у SQL есть разные опции для сетевых протоколов, включая Shared Memory, TCP / IP, Named Pipes и VIA. Вы можете установить конфигурацию для сервера и клиентов (на соответствующих компьютерах) с помощью диспетчера конфигурации SQL Server. Собственный клиент часто будет использовать именованные каналы, которые часто не будут работать по глобальной сети, поскольку (я думаю) он использует широковещательные сообщения для разрешения имен (и, возможно, потребуется открыть больше портов). Таким образом, если SSMS пытается подключиться через именованные каналы, возможно, ей не удастся разрешить имя сервера, тогда как, если sqlcmd использует TCP / IP, он сможет.

Другими словами, первое место, которое я бы посмотрел, было бы в SQL Server Configuration Manager как на сервере, так и на клиенте . Попробуйте отключить все, кроме TCP / IP, или измените порядок поставщиков, чтобы TCP / IP был наверху. Вы можете оставить общую память прямо вверху и включить ее, если хотите, это удобно для подключения к локальной машине.

Answer 3

Вы также можете включить службу браузера SQL на своем сервере, тем самым вы можете увидеть имя экземпляра сервера.

Answer 4

Экземпляр должен быть: homeserver \ instance (обратный слеш, а не прямой слеш)