Не удается подключиться к экземпляру SQL Server с экземпляром другого SQL Server

Я был бы признателен за некоторую помощь, поскольку я застрял в течение 2 дней по этой проблеме!

Сценарий: я могу подключиться к SERVER\INSTANCE с моей машины разработки (и других коллег), но не могу подключиться с другого SQL Server. Ошибка, которую я получаю, - это общий "... проверить правильность имени экземпляра..". Вещи, которые я сделал/подтвердил:

  • Я отключил брандмауэр на целевом (и исходном) сервере, чтобы узнать, является ли это проблемой брандмауэра (это кажется наиболее вероятным, так как я могу подключиться с моей машины, но это не помогло).

  • Я проверил, что работает SQL Browser (что связано с тем, что я могу подключиться с машины разработки)

  • Поскольку оба сервера SQL имеют несколько экземпляров и жестко закодированные порты, я даже убедился, что они были разными портами, если есть конфликт (это не помогло).

  • Я перезапустил SQL Server и проверил, что службы браузера/экземпляра работают

  • Зарегистрированный журнал событий - ничего примечательного

  • Интересно, если я не подключусь по имени экземпляра, но подключись через динамический порт (т.е. SERVER, PORT) со второго сервера, он отлично работает, что говорит о том, что SQL Browser виноват, за исключением того, что он отлично работает локально на сервере и с моей машины разработки.

Любые идеи и предложения? Спасибо.

Изменить: для пояснения комментариев я буду ссылаться на данные SQL Server как SQLA и SQL-данные, отличные от данных.

Изменить №2: добавление дополнительных тестовых примеров/информации:

Информация: Все вышеуказанные тесты были выполнены через интерфейс SSMS для установления соединения с базой данных, задействованные базы данных - это 2012 год.

Новый тестовый пример: я попробовал запустить script, чтобы установить связанный сервер, и обнаружил, что запуск script в SQL Server 2005 отлично работает, но работает с тем же script на сервере SQL Server 2012 (SQLB) не удалось подключиться к SQLA с ошибкой: Сетевые интерфейсы SQL Server: ошибка определения местонахождения сервера/экземпляра [xFFFFFFFF].

Изменить №3: сузили потенциальную проблему:

Загруженный и запущенный PortQry, и при запуске из моего dev-модуля я получаю все экземпляры, возвращаемые с запросом 1434 через UDP, запуск одного и того же запроса из SQLB возвращает NO экземпляров, и он указывает 1434 как FILTERED, тогда как в dev-dev он возвращался как LISTING. Я могу только думать, что это связано с брандмауэром, за исключением того, что я отключил брандмауэр на обеих машинах.

Ответы

Ответ 1

Ваши тестовые примеры, когда вы не можете подключиться к "ServerName\Instance", но можете подключиться к серверу через "ServerName, Port", это то, что происходит, когда вы подключаетесь к сети с помощью Microsoft VPN. (У меня была эта проблема). Для моей VPN-проблемы я просто использую номера статических портов, чтобы обойти ее.

Это связано с тем, что VPN не пересылает пакеты UDP, разрешая только TCP-соединения.

В вашем случае ваш брандмауэр или параметры безопасности или антивирус или что-то другое может блокировать UDP.

Я бы предложил вам проверить настройку брандмауэра , чтобы специально разрешить UDP.

Браузер Artical

При запуске запускает браузер SQL Server и утверждает UDP-порт 1434. SQL Браузер сервера читает реестр, идентифицирует все экземпляры SQL Server на компьютере, и отмечает порты и именованные каналы, которые они используют. Когда сервер имеет две или более сетевых карт, браузер SQL Server будет вернуть все порты для SQL Server. SQL Server 2005 и SQL Поддержка браузера сервера ipv6 и ipv4.

Когда клиенты SQL Server 2000 и SQL Server 2005 запрашивают SQL Server ресурсов, сетевая библиотека клиента отправляет сообщение UDP сервер с использованием порта 1434. Браузер SQL Server отвечает TCP/IP порт или именованный канал запрашиваемого экземпляра. Сетевая библиотека на клиентское приложение завершает соединение, отправив запрос на сервер, используя порт или именованный канал желаемого экземпляр.

Использование брандмауэра

Чтобы связаться с службой браузера SQL Server на сервере за брандмауэром, откройте порт UDP 1434 в дополнение к TCP-порту, используемому SQL Server (например, 1433).

Ответ 2

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

http://technet.microsoft.com/en-us/library/hh231672.aspx

Ответ 3

Наконец-то я нашел эту проблему. Несмотря на то, что брандмауэр был отключен в обоих местах, мы обнаружили, что маршрутизатор в центре обработки данных SQLB активно блокировал UDP 1434. Я смог определить это, установив инструмент PorQry Microsoft (http://www.microsoft.com/en-ca/download/details.aspx?id=17148) и выполнить запрос к порту UDP. Затем я установил WireShark (http://www.wireshark.org/), чтобы просмотреть фактические данные о подключении и нашел связанный с этим маршрутизатор, который отказывался пересылать запрос. Поскольку этот маршрутизатор затронул SQLB, это объясняет, почему все другие соединения работали нормально.

Спасибо всем за ваши предложения и помощь!

Ответ 4

Ты пробовал много. И я чувствую к тебе. Вот идея. Я проследил все, что вы пробовали. Умственное замечание, которое у меня в голове, выглядит следующим образом: "Когда Sql Server не будет подключаться, когда вы все пробовали, подключите свои правила брандмауэра программой, а не порт"

Я знаю, что вы сказали, что вы отключили брандмауэр. Но что-то говорит мне, чтобы я все равно попробовал.

Я думаю, вам нужно открыть брандмауэр "по программе", а не по порту.

http://technet.microsoft.com/en-us/library/cc646023.aspx

To add a program exception to the firewall using the Windows Firewall item in Control Panel.


On the Exceptions tab of the Windows Firewall item in Control Panel, click Add a program.


Browse to the location of the instance of SQL Server that you want to allow through the firewall, for example C:\Program Files\Microsoft SQL Server\MSSQL11.<instance_name>\MSSQL\Binn, select sqlservr.exe, and then click Open.


 Click OK.

ИЗМЕНИТЬ..........

http://msdn.microsoft.com/en-us/library/ms190479.aspx

Я немного облачно, на какую "программу" вы пытаетесь использовать на SQLB?

Это SSMS на SQLB? Или клиентская программа на SQLB?

ИЗМЕНИТЬ...........

Не знаю, поможет ли это. Но я использую это для ping "портов"... и того, что находится вне мира SSMS.

http://www.microsoft.com/en-us/download/details.aspx?id=24009

Ответ 5

У вас есть какие-либо псевдонимы клиентов, определенные на вашей машине разработки? Если да, то также определите их на SQLB. В частности, я подозреваю, что у вас есть псевдонимы клиента в формате InstanceName, которые определяют порты, минуя фактические имена экземпляров и необходимость в SQL Browser (частично). Существуют и другие возможности с псевдонимами клиентов, поэтому просто убедитесь, что они одинаковы.

Чтобы проверить псевдонимы SQL Client, используйте диспетчер конфигурации SQL Server (в Microsoft SQL Server, меню "Пуск" программы). В нем, goto Client Configuration, а затем "Псевдонимы".

Другие вещи для проверки:

  • Этот SQLA и SQLB находятся либо в одном домене, либо между ними нет проблем с доверием.

  • Убедитесь, что SQLB имеет протокол TCP/IP в качестве клиентского протокола (это также находится в диспетчере конфигурации SQL).

По некоторым вашим ответам, я думаю, что вы, возможно, пропустили мои заявления о доменах и трастах. Вы не можете подключиться к SQL "Server\Instance", если не существует достаточного доверия между клиентом и сервером. Это связано с тем, что вся схема Instance-Naming, используемая SQL Sevrer, зависит от SPN (имена основных участников) для обнаружения, местоположения и авторизации, а SPN хранятся в AD. Поэтому, если клиент не находится в одном окне, экземпляр должен иметь возможность зарегистрировать свой SPN, и клиент должен иметь возможность просматривать все леса AD, которые экземпляр сервера зарегистрировал в нем SPN.

Если вы не можете этого сделать, имена экземпляров эффективно не работают, и вместо этого вы должны использовать номер порта (или имя канала). Это то, что я сейчас подозреваю, происходит.

Ответ 6

ну, потратив около 10 дней на решение этой проблемы, я, наконец, понял это сегодня и решил опубликовать решение

в меню "Пуск", введите RUN, откройте его в поле запуска введите SERV.MSC, нажмите "ОК"

убедитесь, что эти две службы запущены SQL Server (MSSQLSERVER) Писатель SQL Server Vss

Ответ 7

  • Мне пришлось указать порт в диспетчере конфигурации SQL > TCP/IP
  • Откройте порт на вашем брандмауэре
  • Затем подключитесь удаленно, используя: "имя сервера/другой экземпляр базы данных (номер порта)"
  • Connected!

Ответ 8

Мне нужно сделать 2 вещи для соединения с именем экземпляра

1. Enable SQL Server Browser (in SQL server config manager)
2. Enable UDP, port 1434 trong file wall (if you using amazon EC2 or other service you need open port in their setting too)

Перезагрузите sql и выполните

Ответ 9

Чтобы решить эту проблему, вы должны убедиться, что на компьютере, на котором размещен SQL Server, выполняется следующее:

  • Убедитесь, что Служба браузера сервера работает
  • Обеспечить связь TCP/IP для каждого экземпляра, с которым вы хотите общаться по сети. введите описание изображения здесь
  • Если вы используете несколько экземпляров, убедитесь, что каждый экземпляр использует другой порт, а порт не используется. например, для двух экземпляров 1433 (порт по умолчанию для экземпляра по умолчанию, 1435 для именованного экземпляра. введите описание изображения здесь
  • Убедитесь, что в брандмауэре есть запись, позволяющая общаться с браузером SQL Server на порту 1434 по протоколу UDP.
  • Убедитесь, что в брандмауэре есть запись, позволяющая связываться с экземплярами SQL Server в портах, назначенных им на шаге 3, по протоколу TCP введите описание изображения здесь