Для чего нужен sql server browser
Применение обозревателя SQL Server
Лекция 8. Создание проекта. Подключение файла данных к проекту
Цель:
1. Изучить службу «SQL Server, браузер»
Служба «SQL Server, браузер»
ОБЛАСТЬ ПРИМЕНЕНИЯ:SQL Server (только в Windows)
Браузер SQL Server выполняется как служба Windows. SQL Server прослушивает входящие запросы к ресурсам Microsoft SQL Server и предоставляет сведения об экземплярах SQL Server, установленных на компьютере. SQL Server предназначен для выполнения трех задач:
· просмотра списка доступных серверов;
· соединения с нужным экземпляром сервера;
· соединения с конечными точками через выделенное административное соединение (DAC).
· при обновлении установки;
· при установке в кластере;
· при установке именованного экземпляра служб Службы Analysis Services.
Историческая справка
Как работает служба «Обозреватель SQL Server»
Если SQL Server настроен на использование протокола TCP/IP, то при запуске экземпляра SQL Server серверу назначается порт TCP/IP. Если включен протокол именованных каналов, SQL Server прослушивает указанный именованный канал. Этот порт или «канал», используется конкретным экземпляром для обмена данными с клиентскими приложениями. Экземпляру по умолчанию при установке назначается TCP-порт 1433 и канал \sql\query, но затем эти значения могут быть изменены администратором сервера при помощи диспетчера конфигурации SQL Server. Поскольку порт или канал может использоваться только одним экземпляром SQL Server, именованным экземплярам, включая SQL Server Express, назначаются другие номера портов и имена каналов. По умолчанию, если и именованные экземпляры и SQL Server Express настроены для работы с динамическими портами, это означает, что доступный порт назначается при запуске SQL Server. При необходимости экземпляру SQL Server может быть назначен конкретный порт, и при соединении клиенты смогут указать именно его. Но если порт назначается динамически, то он может измениться в любой момент после перезапуска 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, браузер» не запущена, то возможность соединения с SQL Server остается только при указании верного номера порта или именованного канала. Например, к экземпляру SQL Server по умолчанию можно подключиться по порту TCP/IP, если он прослушивает порт 1433.
Однако если служба «SQL Server, браузер» не запущена, следующие соединения невозможны.
· Если какой-либо компонент пытается подключиться к именованному экземпляру без полного указания всех параметров (номера порта TCP/IP или именованного канала).
· Если компонент формирует или сохраняет сведения о сервере и экземпляре, которые затем используются другими компонентами для повторного соединения.
· При соединении с именованным экземпляром без указания номера порта или канала.
· При использовании выделенного административного соединения с именованным экземпляром или экземпляром по умолчанию без использования порта TCP/IP 1433.
· При использовании службы перенаправителя OLAP.
· При перечислении серверов в среде Среда SQL Server Management Studio, программе Enterprise Manager или Query Analizer.
· Необходимо обновлять и поддерживать код клиентских приложений, чтобы они соединялись по соответствующим номерам портов.
· Порт, указанный для экземпляра, может быть уже занят другой службой или приложением, работающим на сервере, что может привести к недоступности экземпляра SQL Server.
Кластеризация
SQL Server не является кластеризованным ресурсом и не поддерживает отработку отказа с одного узла кластера на другой. Следовательно, при использовании кластера браузер SQL Server необходимо устанавливать и включать для каждого узла. При работе на кластерах браузер SQL Server прослушивает порт IP_ANY.
Если указан порт IP_ANY, при включении прослушивания на определенных IP-адресах пользователь должен настроить тот же TCP-порт на каждом из IP-адресов, поскольку браузер SQL Server возвращает каждую найденную пару «адрес-порт».
SQL Server Browser Service
The SQL ServerBrowser program runs as a Windows service. SQL Server Browser listens for incoming requests for Microsoft SQL Server resources and provides information about SQL Server instances installed on the computer. SQL Server Browser contributes to the following actions:
Browsing a list of available servers
Connecting to the correct server instance
Connecting to dedicated administrator connection (DAC) endpoints
For each instance of the Database Engine and SSAS, the SQL Server Browser service (sqlbrowser) provides the instance name and the version number. SQL Server Browser is installed with SQL Server.
SQL Server Browser can be configured during setup or by using SQL Server Configuration Manager. By default, the SQL Server Browser service starts automatically:
When upgrading an installation.
When installing on a cluster.
When installing a named instance of the Database Engine including all instances of SQL Server Express.
When installing a named instance of Analysis Services.
Background
Prior to SQL Server 2000 (8.x), only one instance of SQL Server could be installed on a computer. SQL Server listened for incoming requests on port 1433, assigned to SQL Server by the official Internet Assigned Numbers Authority (IANA). Only one instance of SQL Server can use a port, so when SQL Server 2000 (8.x) introduced support for multiple instances of SQL Server, SQL Server Resolution Protocol (SSRP) was developed to listen on UDP port 1434. This listener service responded to client requests with the names of the installed instances, and the ports or named pipes used by the instance. To resolve limitations of the SSRP system, SQL Server 2005 (9.x) introduced the SQL Server Browser service as a replacement for SSRP.
How SQL Server Browser Works
When an instance of SQL Server starts, if the TCP/IP protocol is enabled for SQL Server, the server is assigned a TCP/IP port. If the named pipes protocol is enabled, SQL Server listens on a specific named pipe. This port, or «pipe,» is used by that specific instance to exchange data with client applications. During installation, TCP port 1433 and pipe \sql\query are assigned to the default instance, but those can be changed later by the server administrator using SQL Server Configuration Manager. Because only one instance of SQL Server can use a port or pipe, different port numbers and pipe names are assigned for named instances, including SQL Server Express. By default, when enabled, both named instances and SQL Server Express are configured to use dynamic ports, that is, an available port is assigned when SQL Server starts. If you want, a specific port can be assigned to an instance of SQL Server. When connecting, clients can specify a specific port; but if the port is dynamically assigned, the port number can change anytime SQL Server is restarted, so the correct port number is unknown to the client.
Upon startup, SQL Server Browser starts and claims UDP port 1434. SQL Server Browser reads the registry, identifies all instances of SQL Server on the computer, and notes the ports and named pipes that they use. When a server has two or more network cards, SQL Server Browser returns the first enabled port it encounters for SQL Server. SQL Server Browser support ipv6 and ipv4.
When SQL Server clients request SQL Server resources, the client network library sends a UDP message to the server using port 1434. SQL Server Browser responds with the TCP/IP port or named pipe of the requested instance. The network library on the client application then completes the connection by sending a request to the server using the port or named pipe of the desired instance.
For information about starting and stopping the SQL Server Browser service, see SQL Server Books Online.
Using SQL Server Browser
If the SQL Server Browser service is not running, you are still able to connect to SQL Server if you provide the correct port number or named pipe. For instance, you can connect to the default instance of SQL Server with TCP/IP if it is running on port 1433.
However, if the SQL Server Browser service is not running, the following connections do not work:
Any component that tries to connect to a named instance without fully specifying all the parameters (such as the TCP/IP port or named pipe).
Any component that generates or passes server\instance information that could later be used by other components to reconnect.
Connecting to a named instance without providing the port number or pipe.
DAC to a named instance or the default instance if not using TCP/IP port 1433.
The OLAP redirector service.
Enumerating servers in SQL Server Management Studio, Enterprise Manager, or Query Analyzer.
If you are using SQL Server in a client-server scenario (for example, when your application is accessing SQL Server across a network), if you stop or disable the SQL Server Browser service, you must assign a specific port number to each instance and write your client application code to always use that port number. This approach has the following problems:
You must update and maintain client application code to ensure it is connecting to the proper port.
The port you choose for each instance may be used by another service or application on the server, causing the instance of SQL Server to be unavailable.
Clustering
SQL Server Browser is not a clustered resource and does not support failover from one cluster node to the other. Therefore, in the case of a cluster, SQL Server Browser should be installed and turned on for each node of the cluster. On clusters, SQL Server Browser listens on IP_ANY.
When listening on IP_ANY, when you enable listening on specific IPs, the user must configure the same TCP port on each IP, because SQL Server Browser returns the first IP/port pair that it encounters.
Installing, Uninstalling, and Running from the Command Line
By default, the SQL Server Browser program is installed at C:\Program Files (x86)\Microsoft SQL Server\90\Shared\sqlbrowser.exe.
The SQL Server Browser service is uninstalled when the last instance of SQL Server is removed.
SQL Server Browser can be started from the command prompt for troubleshooting, by using the -c switch:
Security
Account Privileges
SQL Server Browser listens on a UDP port and accepts unauthenticated requests by using SQL Server Resolution Protocol (SSRP). SQL Server Browser should be run in the security context of a low privileged user to minimize exposure to a malicious attack. The logon account can be changed by using the SQL Server Configuration Manager. The minimum user rights for SQL Server Browser are the following:
Deny access to this computer from the network
Deny logon locally
Deny Log on as a batch job
Deny Log On Through Terminal Services
Log on as a service
Read and write the SQL Server registry keys related to network communication (ports and pipes)
Default Account
Setup configures SQL Server Browser to use the account selected for services during setup. Other possible accounts include the following:
Any domain\local account
The local service account
The local system account (not recommended as has unnecessary privileges)
Hiding SQL Server
Hidden instances are instances of SQL Server that support only shared memory connections. For SQL Server, set the HideInstance flag to indicate that SQL Server Browser should not respond with information about this server instance.
Для чего нужен 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, либо имя сервера) и, возможно, целевой порт. Значение данного параметра формируется в момент запуска нашего клиента из значений трех констант, а именно:
Для примера, комбинация значений трех разобранных констант