Sql server browser что это
Sql server browser что это
SqlCmd все о SQL технологиях.
Все что необходимо для изучения и работы с СУБД Microsoft SQL Server, MySQL, MariaDB, MongoDB. Авторские статьи, библиотека фрагментов T-SQL кода, сборник полезных инструментов.
Нужен ли нам сервис SQL Server Browser? Часть 1/3.
Добрый день, уважаемые читатели блога. Не столь давно, а именно в конце весны текущего года, автор данных строк и ваш покорный слуга читал очередной цикл лекций по SQL Server. Как всегда после доклада была масса вопросов, как непосредственно по прочитанной теме, так и вообще, «около SQL-ных». Часть этих вопросов в который уже раз привлекла внимание автора к явному недопониманию SQL-администраторами (в том числе имеющим значительный опыт работы с данной системой) назначения и принципов функционирования такого незаметного, но важного (как минимум, его положено считать таковым) сервиса как SQL Server Browser (или короче — SQL Browser). Зачем он нам вообще? Следует ли держать его включенным или выключенным? Есть ли ему альтернативы? Влияет ли на его поведение конкретная строка подключения, с которой клиент обращается к серверу? И так далее, и тому подобное. Изрядная часть упомянутых администраторов решает все указанные вопросы очень просто: «а как инсталлятор SQL сервера настроил, так оно и работает». Но это явно путь не истинных «SQL-гуру» вообще и не путь читателей блога sqlCMD.ru в частности. Нам, разумеется, нужно четкое и ясное представление о данном компоненте, о «физике» его работы и о критериях по которым мы можем принять взвешенное решение — запускать ли данный сервис автоматически, запускать его же лишь иногда вручную, либо попросту перевести его в состояние disable.
Конфигурация тестового стенда.
Вот такие три настройки релевантны теме нашей сегодняшней беседы. Все дальнейшие описания и обсуждения, в том числе касающиеся обещанного выше инструмента, ведутся именно для них. Если настройки вашего тестового стенда/производственной среды отличаются (а, надо думать, это практически гарантированный случай) вносите соответствующие корректировки в читаемый вами текст/код.
Немного теории.
Хотя статья заявлена как «чисто практическая» уж совсем без теории нам не обойтись — нужна же нам некая «отправная точка», верно? Так вот, давайте максимально сжато и кратко опишем проблематику вопроса.
Как известно, в мире вообще (и в рамках той организации где мы имеем удовольствие работать в частности) есть куча серверов, и не обязательно SQL. SQL Server, как всем хорошо известно, это лишь один из возможных (но совсем не обязательных) сервисов (Windows service) только могущих быть размещенных на этих серверах. Мы, как клиенты-потребители этих многочисленных сервисов, выбираем с каким физическим сервером нам хочется поработать указывая его IP-адрес в сети. Итак, клиент (то есть некое софт-приложение) выбирает конкретный сервер адресуясь к нему по соответствующему IP-адресу. Но — на физическом сервере может быть куча сервисов. Как клиенту обозначить себя как клиента именно SQL Server сервиса? А вот для этого тот самый клиент должен указать не только верный IP-адрес, но и номер порта на этом адресе. Причем сервис еще может выбирать какой порт ему «слушать», а вот клиент выбирать к какому ему порту подключаться — нет (разумеется мы предполагаем что клиенту нужны услуги строго предопределенного сервиса, а не любого какой первый подвернется). В этом смысле первый полностью предопределяет поведение второго. Скажем, в случае тестового стенда автора клиент должен указать IP=192.168.81.3 (см. сетевые настройки тестового стенда чуть выше) и порт=1433 (а об этом поговорим через предложение). Тогда всем и сразу ясно: клиент желает работать с сервером WINR2, с сервисом SQL Server, и причем именно с его экземпляром по умолчанию. Это все потому, что порт 1433 официально закреплен именно за программным продуктом SQL Server, причем уже внутри этого продукта порт закреплен за именно экземпляром по умолчанию. Произвела такое закрепление организация уполномоченная производить подобные операции, IANA (Internet Assigned Numbers Authority). Убедиться, что указанный порт действительно делегирован ею исключительно для нужд SQL Server можно в довольно-таки официальном документе Service Name and Transport Protocol Port Number Registry на сайте самой организации. Из этого документа ясно видно, что под нужды нашего главного героя, то бишь под SQL Server, зарезервированы два порта: 1433 и 1434. И причем каждый порт зарезервирован для двух транспортных протоколов — и для TCP, и для UDP. На текущий момент вам должно быть понятно назначение одной из четырех комбинаций: TCP/1433. Именно по этому протоколу и именно по этому порту каждый клиент обращается к сервису SQL Server и причем именно к экземпляру по умолчанию. Назначение прочих комбинаций протокол/порт станет ясно по ходу изложения материала.
Так вот, вплоть до версии SQL Server 2000 проблем с описанной архитектурой было ровно ноль. Поскольку экземпляров на одном физическом компьютере в те далекие года могло быть ровно 0 или 1, то этот самый единственный экземпляр (сейчас бы мы назвали его «дефолтовым», но тогда он ни в каких обозначениях не нуждался) прямо при инсталляции «садился» на порт 1433 и начинал «слушать» запросы клиентов. Последим же оставалось лишь указать правильный IP-адрес того физического компьютера где данный эксклюзивный экземпляр сервера обретался и — вуа-ля, работай себе на здоровье. С версии 2000 появилось само понятие «множественный экземпляры SQL Server». Да и сам термин «экземпляр» появился в те же дни, ведь до того, как вы уже поняли, термины «экземпляр» и «SQL Server» были эквивалентны и в особом обозначении первого нужды не было. Эти качественные (прежде всего) и количественные (во вторую очередь) изменения существенно подорвали стройную картину мира с единственным 1433-м портом. Ведь каждый экземпляр, как всем хорошо известно, это, на физическом уровне, свой отдельный Windows service. И клиент должен явно указать, желает ли он работать с условным SQL Server 1 (условный же Windows service для него обозначим как sqlsrv1), или же с не менее условным SQL Server 2 (сервис sqlsrv2). А как происходит дифференциация sqlsrv1 от sqlsrv2 при условии что они оба запущены на одном физическом компьютере? Правильно, уже ответили в первом абзаце текущего раздела: эти сервисы должны были «слушать» разные порты, а клиенты, соответственно, адресовать запросы именно на эти прослушиваемые порты.
Когда очертилась новая архитектура решили так: экземпляр по умолчанию — не трогаем вообще. Как он «садился» на 1433, так пусть и дальше поступает. И для клиентов, разумеется, ничего не изменилось. Но вот для любых именованных экземпляров встал вопрос такого сорта: какой порт назначить им? Зарезервировать для каждого такого экземпляра свой порт? Можно было б, но вот последние версии SQL Server позволяют ставить до 50-ти (!) экземпляров на одну машину. Если б каждый производитель софта резервировал бы порты «на всякий» и в таких объемах они б все (порты, а не софт-производители) были бы распределены еще в прошлом веке. И писать свои собственные сетевые сервисы/клиентов стало б решительно невозможно — где свободные порты брать? Поэтому поступили по-джентельменски: оставили официально «забитыми» лишь все те же два порта, 1433 и 1434. Для именованных же экземпляров порешили так:
В общем так или иначе, но если именованный экземпляр запустился — он определенно «оседлал» некий порт X. И вот тут нас ждет финальный вопрос ради которого и весь сыр-бор с SQL Browser и разыгрался: как быть клиентам желающим обратиться именно к именованному экземпляру? Ладно если DBA выбрал второй из двух возможных подходов, тогда такой статический порт можно сообщить клиенту, а именно и скорее всего программисту «ваяющему» этот клиент на одном из высокоуровневых языков программирования. Большой вопрос стоит ли вообще сообщать столь чувствительную информацию как номер порта, открытого в корпоративном файрволе (и как мы увидим далее на этот счет существуют разные точки зрения). Но это хоть возможно чисто технически. Ну а если выбран первый путь (который выбирается установщиком по умолчанию, между прочим)? Да тогда обычно и сам DBA не знает конкретного значения X! Он может, конечно, выяснить эту цифру, но что делать клиенту? Перекомпилироваться каждый раз при перезапуске сервиса (порт-то возможно сменился!)? Или, в лучшем случае, править клиентский ini-файл содержащий строку подключения? Это на пятистах-то рабочих станций? Не смешно.
Хорошо, посмотрим на проблему с такой стороны: если номер порта есть сущность «плавающая», то что бы избежать многократных перекомпиляций/редактирований ini-файла у клиента, вполне очевидно, должна быть более другая и стабильная сущность. Которая сохраняется (и гарантированно сохраняется!) сколько б сервис именованного экземпляра не перезапускали. И такая сущность есть! Зовется она именем экземпляра (instance name) и назначается, обыкновенно, один раз в жизни — в момент инсталляции этого самого экземпляра. Разумеется, и это имя не стоит размещать на билбордах города, однако имя экземпляра, несомненно, менее «хак-чувствительная» информация по сравнению с конкретным номером открытого порта. И вот ее уж точно можно (и даже, без вариантов, нужно) свободно сообщить программисту клиентского приложения. Однако и это еще не конец истории. Даже если клиент знает имя экземпляра это, само по себе, не поможет ему подключиться к требуемому сервису ни на йоту. Потому что «генеральное» правило пользования сервиса осталось все тем же: указать правильный IP-адрес для подключения к нужному компьютеру, плюс указать порт (а не какое-то там имя) для пользования услугами нужного сервиса в рамках этого компьютера. Ну IP-адрес (а точнее и скорее всего просто доменное имя) сервера с SQL Server наш программист, конечно, знает. А вот порта он как не знал, так и продолжает, даже если DBA сообщает ему корректное имя экземпляра.
В общем, вы уже догадались: нам нужен некто/нечто способное провести сопоставление (по нашему, по «IT-шному» — маппирование) «имя экземпляра» → «номер порта, этим экземпляром прослушиваемого». Так вот если сказать совсем по простому, то 99% функционала изучаемого нами сервиса SQL Browser предназначен для проведения именно такого маппирования. То есть, с совсем небольшой натяжкой можно сказать, что SQL Browser решает эксклюзивно единственную задачу: принять от клиента имя экземпляра и сообщить ему взамен номер порта, на котором тот экземпляр «сидит». Еще 1% функционала сводится к выдаче тем же сервисом списка всех экземпляров SQL Server на данном физическом компьютере, но, хотя мы и коснемся и этого функционала в дальнейшем материале, он совершенно точно является вторичным на фоне основной «мета-задачи» маппирования.
Инструмент тестирования.
Итак, как вы уже поняли из вводной части статьи, отключение сервиса SQL Browser может привести к одной единственной «маленькой» проблемке: ни один клиент не сможет подключиться к нашему SQL серверу. Может показаться, что проблемка в принципе касается лишь именованных экземпляров, и, в большой степени, это замечание справедливо. Однако, как будет показано далее, возможны проблемы и с экземпляром по умолчанию, правда лишь в весьма специфических условиях и особой конфигурации.
Под инструментом тестирования автор данных строк понимает некоторую программу позволяющую за несколько секунд убедиться — будет ли тот или иной клиент работать (или, более точно, как минимум подключаться) с указанным экземпляром в случае запущенного/остановленного сервиса SQL Browser. Сразу запомним себе правило:
Итак, вся суть тестирования упирается не более чем в «подсовывании» клиенту различных строк подключения и наблюдения за тем, что он нам скажет в ответ на попытку соединиться c SQL Server. Вполне понятно, что технически реализовать эту совсем простую задачу можно десятками (если не сотней) способов. Можно было взять банальный SQL Server Management Studio и использовать его как клиента подключающегося с различными connection strings. Не менее блестяще с той же задачей справилась бы утилита командной строки, чье имя дало название данному блогу. Однако, по ряду причин (среди которых и образовательная), автор решил создать супер-элементарное консольное приложение (Visual Studio у всех есть?), где требуемая строка подключения формируется редактированием трех констант — двух строковых и одной целочисленной. Разумеется, по вкусу, вы вольны переделать данный код таким образом, что бы значения брались из командной строки, или даже из внешнего файла конфигурации, однако автор стремился к абсолютному минимализму и вот что у него получилось:
using System ;
using System.Text ;
using System.Data.SqlClient ;
namespace TestSQLbrowser
<
class Program
<
const string instName = null ;
const string ipNum = «192.168.81.3» ;
const int portNum = 0 ;
Код настолько незатейлив, что будет понятен даже если «магическое» словосочетание «си-шарп» не говорит вам ровным счетом ничего. Наш главный предмет исследования, строка подключения, формируется в переменной conn и состоит из параметров этой строки разделенных точкой с запятой. Четыре параметра у нас имеют фиксированное значение, пробежимся сначала по ним:
К рассмотренным только что четырем статическим параметрам «приклеивается» параметр пятый, тот самый Data Source. Это, с большим опережением, самый важный параметр любой строки подключения, именно здесь задается целевой сервер (через IP, либо имя сервера) и, возможно, целевой порт. Значение данного параметра формируется в момент запуска нашего клиента из значений трех констант, а именно:
Для примера, комбинация значений трех разобранных констант
Служба обозревателя SQL Server (компонент Database Engine и SSAS)
Браузер SQL Server выполняется как служба Windows. SQL Server прослушивает входящие запросы к ресурсам Microsoft SQL Server и предоставляет сведения об экземплярах SQL Server, установленных на компьютере. SQL Server предназначен для выполнения трех задач:
просмотра списка доступных серверов;
соединения с нужным экземпляром сервера;
соединения с конечными точками через выделенное административное соединение (DAC).
Компонент Database Engine и Службы SSAS получают от службы «Браузер SQL Server» (sqlbrowser) имя и номер версии для каждого экземпляра. Браузер SQL Server устанавливается вместе с SQL Server.
Браузер SQL Server настраивается в ходе установки или с помощью диспетчера конфигурации SQL Server. По умолчанию служба «Браузер SQL Server» запускается автоматически:
при обновлении установки;
при установке в кластере;
при установке именованного экземпляра компонента Компонент Database Engine, включая все экземпляры SQL Server Express;
при установке именованного экземпляра служб Службы Analysis Services.
Историческая справка
Как работает служба «Обозреватель SQL Server»
После запуска SQL Server запускается браузер и пытается занять UDP-порт 1434. SQL Server читает реестр, находит все экземпляры SQL Server на данном компьютере и помечает используемые ими порты и именованные каналы. Если сервер имеет несколько сетевых плат, браузер SQL Server возвращает первый допустимый порт, который найден для SQL Server. SQL Server поддерживает протоколы ipv6 и ipv4.
При запросе клиентом SQL Server ресурсов SQL Server клиентская сетевая библиотека передает на сервер UDP-сообщение через порт 1434. SQL Server Браузер в ответ сообщает TCP/IP-порт или именованный канал запрошенного экземпляра. Затем сетевая библиотека клиентского приложения завершает соединение, отправляя запрос на сервер с указанием номера порта или имени канала, относящегося к нужному экземпляру. Служба обозревателя SQL Server не выполняет разрешение портов для экземпляров по умолчанию.
Применение обозревателя SQL Server
Если какой-либо компонент пытается подключиться к именованному экземпляру без полного указания всех параметров (номера порта TCP/IP или именованного канала).
Если компонент формирует или сохраняет сведения о сервере и экземпляре, которые затем используются другими компонентами для повторного соединения.
При соединении с именованным экземпляром без указания номера порта или канала.
При использовании выделенного административного соединения с именованным экземпляром или экземпляром по умолчанию без использования порта TCP/IP 1433.
При использовании службы перенаправителя OLAP.
При перечислении серверов в среде SQL Server Management Studio, программе Enterprise Manager или Query Analizer.
Необходимо обновлять и поддерживать код клиентских приложений, чтобы они соединялись по соответствующим номерам портов.
Кластеризация
SQL Server не является кластеризованным ресурсом и не поддерживает отработку отказа с одного узла кластера на другой. Следовательно, при использовании кластера браузер SQL Server необходимо устанавливать и включать для каждого узла. При работе на кластерах браузер SQL Server прослушивает порт IP_ANY.
Если указан порт IP_ANY, при включении прослушивания на определенных IP-адресах пользователь должен настроить тот же TCP-порт на каждом из IP-адресов, поскольку браузер SQL Server возвращает каждую найденную пару «адрес-порт».
Установка, удаление и запуск из командной строки
По умолчанию браузер SQL Server устанавливается в C:\Program Files (x86)\Microsoft SQL Server\90\Shared\sqlbrowser.exe.
SQL Server В целях диагностики браузер можно запустить из командной строки с параметром -c :
Безопасность
Права доступа учетной записи
Запретить сетевой доступ к этому компьютеру.
Запретить локальный вход в систему.
Запретить вход в систему в качестве пакетного задания.
Запретить вход в систему через службы терминалов.
Вход в систему в качестве службы.
Учетная запись по умолчанию
Программа установки настраивает браузер SQL Server для использования учетной записи, выбранной для служб при установке. Можно указать другую учетную запись:
Учетная запись локальной службы
Учетная запись локальной системы (не рекомендуется за избыточностью прав доступа).
Скрытие экземпляра SQL Server
Применение брандмауэра
Для связи со службой браузера SQL Server на сервере, защищенном брандмауэром, в дополнение к TCP-порту SQL Server (например 1433) откройте UDP-порт 1434. Сведения о работе с брандмауэром см. в разделе «Практическое руководство. Настройка брандмауэра для доступа SQL Server» в документации по SQL Server.
Sql server browser что это
SqlCmd все о SQL технологиях.
Все что необходимо для изучения и работы с СУБД Microsoft SQL Server, MySQL, MariaDB, MongoDB. Авторские статьи, библиотека фрагментов T-SQL кода, сборник полезных инструментов.
Нужен ли нам сервис SQL Server Browser? Часть 2/3.
SQL Browser и экземпляр по умолчанию.
Экземпляр по умолчанию имеет стандартный порт 1433.
Для начала запустим SQL Server Configuration Manager и убедимся, что тестируемый нами сервис выключен:
В той же утилите убедимся, что сам экземпляр по умолчанию запущен и слушает запросы клиентов. Если вы меняли порт этого экземпляра (что маловероятно, но не исключено), верните его в стандартное значение 1433.
Конфигурируем наш тест-клиент
и запускаем его. Разумеется — успех:
Пробуем подключится без указания порта (через присвоение константе portNum значения 0) и снова полный OK. Итак, факты говорят нам о том, что для «стандартного» экземпляра по умолчанию (то бишь «садящегося» на порт 1433) сервис SQL Browser тотально не нужен. Не менее очевидный факт говорит о том, что этот самый стандартный порт клиент может как указывать в строке подключения, так и игнорировать его.
Что будет если в указанной ситуации все-таки запустить сервис SQL Browser? Ничего! Ну то есть на его запуск и поддержку в рабочем состоянии уйдет некая доля RAM/CPU нашего сервера (впрочем, это будут сущие крохи) но во всем остальном изменений будет ровно 0. Финальный результат будет тот же (успешное подключение клиента) и достигаться с технической точки зрения он будет точно так же — прямым и безусловным обращением к порту 1433. Иными словами, при подключении к экземпляру по умолчанию никакие «посредники» ни нам, ни нашим клиентам не требуются. И низкоуровневая сетевая библиотека реализующая физическое подключение попросту игнорирует факт наличия обсуждаемого сервиса даже не пытаясь отправить последнему хотя бы один сетевой пакет. Точка.
Наконец, любопытно отметить, что для нашего «сетевого, но локального» подключения целевой сервер можно задать пятком способов. То есть, константе ipNum можно с равным успехом присвоить такие строки:
И, представьте себе, любой вариант приведет к успешному подключению к требуемому экземпляру по умолчанию! Правда, тут стоит сделать небольшое ответвление от основной канвы нашей беседы и рассмотреть пару настроек сетевого протокола сервера не имеющих никакого отношения к SQL Browser, но имеющих прямое отношение к только что приведенному списку и заявлению «работает все!» относительно него.
Listen All и индивидуальные IP-адреса.
Вы, несомненно, знаете, как открыть окно свойств протокола TCP/IP для того или иного экземпляра:
Указанное окно состоит из двух закладок — Protocol и IP Addresses. Опции настроек в них фигурирующие более-менее ясны и понятны, но автор регулярно получает от своих слушателей два вот каких вопроса.
Во-первых, что делает и на что влияет опция Listen All на первой закладке:
А, во-вторых, что на второй закладке делают разделы опций называемые IPx (где x — целое число начиная с 1) и на что влияют опции Active и Enabled в пределах каждого такого раздела:
Действительно, данные опции затрагиваются столь редко, что найти им вменяемое объяснение тяжело даже в англоязычной SQL-литературе. Вот и в нашей беседе менять их значения нет ровным счетом никакой необходимости, они просто нам «под руку подвернулись». А история с ними такая.
Сразу после запуска сервис любого экземпляра опрашивает все физические сетевые адаптеры того компьютера где этот самый сервис был запущен на предмет всех IP-адресов под которые данные сетевые адаптеры были в свое время (очевидно — в момент их инсталляции) сконфигурированы. После чего под каждый такой адрес заводится раздел IPx как это показано на последнем рисунке. Под какой именно адрес заведен данный раздел видно из значения опции IP Address в границах самого раздела. Скажем на той же последней иллюстрации видно, что раздел IP1 заведен для обслуживания адреса 192.168.81.3. А всего на машине автора с ее единственным сетевым адаптером сервис SQL Server обнаружил четыре сетевых адреса и, как легко догадаться, завел четыре раздела IP1-IP4, а именно:
Итого, если Listen All установлен в Yes, то именно в этом, показанном только что разделе, следует произвести выбор между динамическим и статическим назначением номера порта, а так же указать конкретную цифру если выбран второй вариант. На разделы IPx можно вообще не обращать внимания, и лучше их даже свернуть, благо у каждого такого раздела есть предусмотрительно заготовленная кнопка «плюс-минус» именно для этих целей. Ну а все вместе это означает: клиент может подключаться к серверу по любому адресу, причем номер порта будет единым для всех адресов. Помните, что в конце предыдущего раздела автор заметил, что к экземпляру по умолчанию наш «тест-клиент» может подключаться (помимо прочего) и по адресу 192.168.81.3, и по адресу 127.0.0.1? Так вот это — одно из следствий установки опции Listen All в значение Yes. Кстати говоря, это значение разбираемой опции по умолчанию.
Ну а если для той же опции выбрать прямо противоположное значение No? А вот тогда игнорируется уже как раз раздел IPAll на закладке IP Addresses, а «в игру» вступают разделы IPx. Ведь когда мы можем захотеть выбрать No для Listen All? Когда, очевидно, один из зарегистрированных на сетевой плате адресов нам «не нравится». Ну вот не хотим мы принимать подключения по 192.168.81.3, и все тут! По 127.0.0.1 — да с нашим удовольствием, а по 192.168.81.3 — ни-ни. Такой разворот вопроса, конечно, не шибко характерен для реальных условий реальных IT-систем, но, не менее несомненно, что указанное желание может возникнуть у того или иного DBA/системного администратора. В этом случае последний устанавливает Listen All в No, после чего ему не остается ничего другого как поработать с каждым из зарегистрированных IP-адресов персонально. А именно, для каждого отдельного IP-адреса требуется решить:
Да, вы все поняли правильно. Есть возможность принимать подключения по 192.168.81.3 на порт 1433, а по 127.0.0.1 — на порт 17098, а то и вовсе на порт назначаемый динамически. Для этого, как легко убедиться из предпоследней и последней иллюстраций, каждый IPx раздел имеет свои собственные опции TCP Dynamic Port/TCP Port. Вот именно через них мы и проводим подобный выбор.
Ну а Enabled является уже самым настоящим и реальным переключателем. Выставляя его в Yes мы разрешаем клиентам подключение по указанному адресу, в No — запрещаем.
Допустим, что для нашего экземпляра сервера по умолчанию Listen All имеет дефолтовое же значение Yes. Запустим наш тест-клиент и убедимся, что последний прекрасно устанавливает соединение как по 192.168.81.3, так и по 127.0.0.1:
Try connect to: 127.0.0.1
Connection is established!
Try connect to: 192.168.81.3
Connection is established!
Переведем Listen All в No, опцию Enabled для секции IP1 тоже в No, а Enabled для секции IP3 в Yes. Не забудем рестартовать сервис экземпляра по умолчанию, что бы новые настройки были «подхвачены». Подключение по 127.0.0.1 (IP3) осталось, подключение по 192.168.81.3 (IP1) более невозможно:
Try connect to: 127.0.0.1
Connection is established!
Не забудьте по окончанию опытов вернуть Listen All в гораздо более привычное ей значение Yes!
Экземпляр по умолчанию имеет нестандартный порт.
Возвращаемся в основную «колею» рассказа. Как мы убедились парой разделов назад, если экземпляр по умолчанию занимает предписанный ему IANA 1433-й порт, то клиент подключается к нему прекрасно и услуги обсуждаемого сервиса SQL Browser совершенно не требуются. Вопрос более интересный — что если тот же экземпляр предпочтет выбрать (не сам конечно, а через управляющего им DBA) нестандартный порт? А то и вовсе возьмет DBA да и сконфигурирует динамическую настройку порта в момент запуска сервиса — что тогда?
Убедившись, что сервис SQL Browser продолжает бездействовать, изменим порт прослушиваемый экземпляром по умолчанию на, допустим, 15888. Как нам хорошо известно из предыдущего раздела такие изменения следует производить на закладке IP Addresses окна свойств протокола TCP/IP, а именно в разделе IPAll последней:
Не забыв рестартовать сервис самого экземпляра по умолчанию запустим наш тест-клиент с теми же настройками, что были у него при последнем успешном подключении, а именно:
Результат, в общем-то, ожидаем:
И то сказать, что же мы хотим от сетевой библиотеки клиента? Что бы та наугад перебирала все доступные порты удаленного сервера с мыслью «авось повезет»? Нет уж — не соизволил клиент явно указать порт, а на предполагаемом порту 1433 ничего не нашлось — проблемы клиента. То есть наши с вами.
Что ж — запустим в работу «виновника торжества»
и будем надеяться, что он подскажет клиенту правильный, хоть и нестандартный порт. Запускаем клиента еще раз, однако результат тот же самый что был при остановленном сервисе SQL Browser — неуспех подключения. Тогда пробуем сконфигурировать клиента с явным указанием номера порта:
Однако, надо думать, что если порт указан явно, то никакое мапирование и не требуется? В подтверждении этой идеи останавливаем SQL Browser и убеждаемся, что мы молодцы и все поняли правильно — клиент продолжает подключаться к нашему нестандартному экземпляру по умолчанию и при выключенном сервисе SQL Browser.
Попробуем назначить нашему экземпляру по умолчанию порт динамически, во время старта сервиса. Для этого в том же разделе IPAll стираем все значения для опции TCP Port, а для TCP Dynamic Port выставляем 0:
И снова рестартуем сервис экземпляра по умолчанию. Убеждаемся, что история полностью повторяется — ни с запущенным, ни с остановленным сервисом SQL Browser клиент не способен подключиться к экземпляру по умолчанию если только он не укажет верный порт. Кстати, раз уж речь об этом зашла, скажите-ка — а откуда вы, как DBA, возьмете номер порта назначенного экземпляром самому себе динамически, дабы затем сообщить это число тому же программисту клиента? Не сомневаюсь, что вы привели как минимум один способ решения этой нехитрой задачи, но скорее всего, вы предложили несколько вариантов. Автор и сам знает их порядка пяти, но остановимся на самом простом — вновь откроем окно свойств протокола TCP/IP → закладка IP Addresses → раздел IPAll. На этот раз мы там видим вовсе не 0 установленный как раз перед рестартом сервиса, а вот такую цифру:
Вот и требуемый порт нашелся — 1069, на сей раз. Разумеется, если мы сконфигурируем наш тест-клиент вот так:
будет ожидать нас вне зависимости от того, работает ли сервис SQL Browser или же он остановлен. Более того, если бы в рамках экспериментов текущего раздела мы «копнули» бы чуть глубже, и с помощью той или иной утилиты посмотрели бы какие сетевые пакеты шлет наш клиент к SQL Browser и какие пакеты получает в ответ, то выяснили бы очень занятную вещь: никакие не шлет и уж тем более никакие не получает.
Слов было сказано немало, а финальный вывод умещается в одну строку: сетевые клиентские библиотеки Microsoft при подключении к экземпляру по умолчанию тотально игнорируют сам факт существования такого программного продукта как сервис SQL Browser. Причем конкретный порт (в том числе и стандартный 1433) прослушиваемый указанным экземпляром на это игнорирование никак не влияет. Точка и end of story.
Экземпляр по умолчанию и выделенное административное соединение (DAC).
Про специальное, «админское», подключение к серверу, оно же dedicated administrator connection, оно же DAC знают, конечно же, все. Мы не будем останавливаться на вопросах «когда» и «в каких случаях» — наша статья не об этом. Мы сфокусируемся на вопросе как реализовать это подключение, то бишь как нам соединится с сервером именно по DAC, а не по линии для простых «юзеров».
Всеми нами любимый BOL в статье Служба браузера SQL Server сообщает, что:
Как вы помните, в начале статьи автор отвел 99% функционала сервиса SQL Browser на задачу номер 2 из последнего списка и 1% на задачу 1. А сколько же приходится на третью задачу? Ведь похоже, без обсуждаемого нами в настоящий момент сервиса мы просто не сможем воспользоваться DAC? Ну — давайте смотреть. Напомню, что в настоящий момент упомянутый сервис у нас выключен.
Для примера возьмем того клиента подключение к DAC через которого реализуются, наверно, чаще всего. Поскольку мы будем пытаться «DAC-подключиться» к экземпляру по умолчанию и при этом на том же самом компьютере, на котором запускается указанная утилита, то синтаксис для такого подключения будет архипростым:
Все отлично подключено и утилита готова принимать наши команды и отправлять их по DAC-каналу. Ладно, а если мы хотим в Management Studio произвести такое же подключение? Попробуем:
И снова все прекрасно, все подключено. Так в чем смысл замечания BOL? Какая связь между SQL Browser и DAC-подключением? А дело, как выясняется, в следующем.
Как было пояснено в начале статьи, в «давние-стародавние» времена, в организации IANA под нужды программного продукта SQL Server были зарегистрированы не один порт, а два: 1433 (про него нам добавить решительно нечего) и 1434. Как вы думаете, а вот этот второй — зачем регистрировался? Да что б по нему «DAC-коннекшен» устанавливался! То есть DAC это не какой-то там резервный сетевой адаптер, плюс отдельный сетевой кабель, плюс вспомогательный сервис. Все значительно скромнее — просто отдельный порт. Подключились к экземпляру по умолчанию через 1433? Так это обычное «юзерское» подключение. Подключились к тому же самому через 1434? Так это «необычное» DAC-подключение. Наш тест-клиент тоже может запросто необычно подключиться, надо лишь его настроить:
Небезынтересно отметить, что в этом последнем эксперименте имя целевого сервера указанное как WINR2/127.0.0.1/.(точка)/(local) «прокатывает» а вот указанное как 192.168.81.3 — нет. Связано это с тем, что DAC подключения принимаются только от локальных клиентов. А от удаленных (пусть даже с приставкой «псевдо-») — нет. Впрочем, сервер можно настроить так, что бы запросы на DAC-подключения принимались и от последних тоже, но это уже отдельная история.
Итак, пока прослушивание DAC-запросов идет для экземпляра по умолчанию через порт 1434 наш многострадальный сервис SQL Browser вновь оказывается «не при делах». Уже начинается закрадываться вопрос — а он вообще когда-нибудь включится в работу? Ну это мы еще посмотрим, а пока что отметим — теоретически допускается возможность, что экземпляр по умолчанию выберет для прослушивания порт иной, чем 1434. Автор, строго говоря, не видел такого ни для одного экземпляра по умолчанию за всю свою 12-ти+ годичную SQL-карьеру. Все имели «DAC-порт» под номером 1434. Кроме того, если такое случится, становится непонятным — а к чему IANA «напрягалась», порты там всякие регистрировала? Однако считается, что такое не исключено. Так вот только в этом (мифическом, с точки зрения автора) случае у SQL Browser появляется шанс «выйти на сцену». Потому что тогда, та же утилита sqlcmd обнаружив у себя в командной строке флаг -A, но не обнаружив DAC на положенном ему месте, то бишь на порту 1434, обратится-таки к указанному сервису с сакраментальным вопросом «а где он»? На что получит вполне вежливый ответ — «а на порту 12707 он» (это пример, конечно). После чего DAC-соединение будет успешно установлено. Однако, даже в этом случае, сама вероятность возникновения которого исчезающе мала, можем ли мы утверждать, что SQL Browser совершенно необходим нам для реализации DAC-подключения? Не можем мы такого утверждать! Потому что:
После чего SQL Browser вновь оказывается не у дел, ибо в нашем тест-клиенте мы пишем:
в утилите командной строки мы пишем
ну а в студии так и вовсе:
В завершении текущего раздела отметьте себе, что в отличии от нормального порта «для юзеров», порт для DAC-подключения невозможно назначить статически. Ну, по крайней мере, официально невозможно. Всякие недокументированные «хаки» никто не отменял разумеется, однако это не тот случай что бы уделять им хоть сколько-нибудь пристальное внимание. Удовлетворитесь портом 1434 и не выдумывайте, мой вам совет. Так вот «DAC-порт» всегда выбирается динамически, однако, как было отмечено выше, именно для экземпляра по умолчанию он, то есть сервис того самого экземпляра, обязан динамически выбирать порт 1434 (то есть по факту привязка все же статична), ибо IANA и все такое. Кстати, аналогичное поведение прослеживается и для именованных экземпляров. Если при первом в жизни старте такого экземпляра для DAC-подключения был динамически выбран порт с номером X, то этот X сохраняется при всех последующих перезапусках того же экземпляра, если только не будет самых серьезных оснований (как пример — сторонний софт взял и захватил тот же порт X под свои нужды) это число изменить. И еще одно, кстати — существует довольно широко распространенное заблуждение, что все экземпляры SQL Server на одном физическом компьютере используют для DAC-подключений один и тот же порт, а именно 1434. Так вот — отнюдь, и если подумать становится понятным что это невозможно и чисто технически. Ситуация идентична «нормальным» портам, то есть у каждого экземпляра свой, персональный порт для выделенных административных соединений. Впрочем к обсуждению именованных экземпляров мы как раз и переходим.