Установка служб SQL Server R Services (в базе данных). MS SQL Server. Обслуживание системных баз данных

Помощь 26.05.2019
Помощь

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

Диспетчер настроек SQL Server - интерактивное приложение для управления всеми службами на основе SQL Server, сетевыми протоколами, портами средства прослушивания и создания псевдонимов серверов. Диспетчер настроек SQL Server (SSCM) доступен в иерархии пунктов меню Start\Microsoft SQL Server 20xx\Configuration Tools\SQL Server Configuration Manager в версиях Microsoft Windows, предшествующих выпуску Windows 8 и Windows Server 2012. В последних указанных версиях операционной системы просто выполните поиск по словам SQL Server и выберите «Диспетчер настроек SQL Server» из списка приложений. При первом обращении к SSCM программа выглядит примерно так, как показано на экране 1 (в качестве примера в данной статье используется SQL Server 2014).

Экран 1. Диспетчер настроек SQL Server

Настройка

Рассмотрим более подробно возможные действия, разрешенные в диспетчере SSCM. Каждый элемент на левой панели представляет одну или несколько задач, которые можно выполнить в диспетчере SSCM. В некоторых случаях есть как 64-разрядный, так и 32-разрядный вариант. В данной статье мы остановимся на 32-разрядном варианте. Сегодня Microsoft SQL Server размещается на 32-разрядных серверах только в том случае, если:

а) вы обладатель старой версии SQL Server;

б) скорее всего, лишаете экземпляр SQL Server ценных ресурсов оперативной памяти.

Перечислим действия, доступные в диспетчере SSCM (см. экран 2).
Экран 2. Действия, доступные в SSCM
  • Службы SQL Server. Данное действие позволяет запускать, останавливать и перезапускать все службы, связанные с Microsoft SQL Server. Кроме того, вы можете изменять учетные записи службы, поведение при запуске и дополнительные функции и параметры запуска в зависимости от службы.
  • Сетевые настройки SQL Server. Это действие позволяет включать и отключать конкретные сетевые протоколы: Shared Memory, Named Pipes и TCP/IP, а также настраивать дополнительные параметры для каждого из них.
  • Настройки собственного клиента SQL Server (на сегодня версия 11.0). Это действие позволяет установить порядок, в котором клиенты будут использовать специально включенные протоколы для подключения к настраиваемому экземпляру SQL Server. С его помощью можно создавать псевдонимы для экземпляра SQL Server, чтобы различные приложения конечных пользователей могли подключаться к серверам с именами, отличными от действительного имени сервера. Это делается на случай, если вы не можете изменить строки подключения при переносе баз данных приложения, но все же хотите обеспечить преемственность или скрыть настоящее имя сервера от конечных пользователей. Рассмотрим каждое из этих действий подробнее.

Службы SQL Server

Связанные службы SQL Server могут (и по идее должны) управляться и настраиваться из диспетчера SSCM, а не API-интерфейса services.msc. Как отмечалось выше, мы можем управлять не только поведением при запуске и учетной записью службы, но и дополнительными параметрами каждой службы (см. экран 3).

  • SQL Server Integration Services. Дополнительные настраиваемые параметры отсутствуют.
  • SQL Server Analysis Services. Дополнительные настраиваемые параметры отсутствуют.
  • SQL Server Service:

1. FILESTREAM. Эта настройка позволяет включить или отключить доступ T-SQL, доступ файлового ввода-вывода, доступ к удаленному клиенту и установить имя общего ресурса FILESTREAM.

2. Высокий уровень доступности AlwaysOn. Эта настройка дает возможность включить или отключить группы доступности AlwaysOn, а также настроить отказоустойчивый кластер Windows (WFCS), на котором построена группа доступности.

3. Параметры запуска. Диспетчер SSCM позволяет назначить специальные параметры запуска, вступающие в силу для экземпляра. В вашем распоряжении всегда будет по крайней мере три параметра запуска для любого экземпляра SQL Server, чтобы обеспечить корректный запуск Microsoft SQL Server:

  • -d. Указывает местонахождение файла данных (.mdf) базы данных master.
  • -l. Указывает местонахождение файла журнала транзакций (.ldf) базы данных master.
  • -e. Задает местонахождение файла журнала ошибок экземпляра.

Почему именно эти три параметра? Потому что master функционирует как обращенный вовне «мозг» экземпляра SQL, работающий в сочетании со скрытой базой данных Resource, предоставляя все необходимые метаданные, необходимые для запуска экземпляра SQL Server. Требуется использовать журнал ошибок для записи каждого шага процесса запуска.

Дополнительные параметры могут быть настроены, в частности, для запуска сервера в однопользовательском режиме с целью поиска неисправностей (-m); запуска экземпляра с минимальным набором настроек (-f) в случаях, когда необходимо обойти неудачный параметр, способный привести к ухудшению отклика экземпляра; установки флагов трассировки, изменяющих базовое поведение Microsoft SQL Server (-T). Мне приходилось использовать -f для обхода неудачных настроек, когда я пытался продемонстрировать проблемы ограничения памяти и устанавливал максимальное значение памяти сервера столь малым, что не мог запустить SQL Server. Конечно, большинство администраторов баз данных устанавливают несколько флагов трассировки за время своей профессиональной деятельности на каждом из серверов SQL Server через параметр -T, но подробнее об этом я расскажу в другой статье.

Полный список параметров запуска можно найти в официальной документации Microsoft (https://msdn.

microsoft.com/en-us/library/ms190

4. Advanced («Дополнительно»). Вкладка Advanced для службы SQL Server (см. экран 4) обеспечивает возможность изменить каталог дампа для экземпляра, а также настроить механизм передачи отзывов в компанию Microsoft для дальнейшей работы над продуктом. Кроме того, вы получаете возможность читать (но не изменять) дополнительные параметры, перечисленные ниже.

  • SQL Server Reporting Services. Мы можем управлять некоторыми базовыми параметрами служб для SQL Server Reporting Services (SSRS), но для этой службы существует отдельный интерфейс. Я не рекомендую использовать SSCM для всех аспектов настройки SSRS, хотя некоторые из них доступны.
  • SQL Server Browser («Обозреватель SQL Server»). Помимо поведения при запуске и учетной записи службы, существует несколько дополнительных настроек этой службы, которыми можно управлять, кроме каталога дампа и журнала ошибок. Рекомендуется отключить эту службу, если только вы не располагаете несколькими экземплярами SQL Server на одном узле.
  • SQL Server Agent Service («Служба агента SQL Server»). Аналогично многим другим службам, вы можете настраивать только каталог дампа, ведение журнала ошибок и передачу отзывов, наряду с поведением при запуске и учетной записью службы.

Сетевые настройки SQL Server

Действия по сетевой настройке SQL Server позволяют включить любой или все три сетевых протокола, доступные в Microsoft SQL Server: Shared Memory, Named Pipes и TCP/IP.

Shared Memory и Named Pipes обеспечивают доступ сетевого компьютера к SQL Server, а TCP/IP определяет способы связи сетевых устройств с экземпляром SQL Server. Да, Named Pipes можно применять в среде Windows, но вы теряете все преимущества обхода сетевого стека при использовании Named Pipes между удаленными серверами. Параметры настройки Shared Memory начинаются и кончаются статусом включения. Named Pipes, в дополнение к статусу «включен-отключен», позволяет задать имя канала для SQL Server. Наконец, TCP/IP позволяет включать и отключать этот протокол, наряду с изменением порта, по которому SQL Server прослушивает запросы.

Настройка собственного клиента SQL Server

Этот набор действий позволяет установить очередность обработки запросов в SQL Server. Кроме того, вы сможете отключить названные протоколы для клиента, а также назначить имя канала и номер порта.

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

Зачастую база работает в «нормальных» условиях. Что под этим подразумевается:

  • Сервер SQL хорошо «питается», т.е. объем ОЗУ предоставляемой для работы SQL сервера выбирать из расчёта 70% от размера всех mdf файлов баз данных.
  • Процессор не загружен более чем на 50% в течении 90% времени.
  • Имеется достаточное место на дисках (в частности для сортировки используется база temp.db, 1С ее использует вообще для всей своей жизнедеятельности, потому стоит заранее озаботиться местом на диске с этой базой).
  • Режим восстановления базы данных - «Простой». (Эмпирически выяснено, что большой ldf файл тормозит 1с-ку, а возможность восстановления по лог-файлу весьма сомнительна).

Так же стоит учитывать несколько нюансов:

  • При использовании Standard редакции SQL, при полном перестроении индекса, все пользователи будут отключены от базы, потому стоит это учитывать при решении проведения Weekly плана обслуживания (план будет описан ниже).
  • Стоит учитывать, что сервер 1С тоже потребляет память, особенно если используются тонкие клиенты или веб-службы.
  • Самому SQL лучше ограничить в параметрах сервера максимальный объем ОЗУ, дабы по достижению критической массы, он заранее начинал очищать ненужные данные из ОЗУ. Да и чтоб разрастаясь не вгонять весь сервер в ступор.

Рационально при нормальных условиях использовать 2 плана обслуживания Weekly (раз в неделю) и Daily (в остальные 6 дней недели).

Weekly

Общий вид

По пунктам плана обслуживания:

  1. Перестроение индекса. Смысл задачи в удалении всех имеющихся индексов и установки новых. (грубо говоря инвентаризация и расстановка всего по порядку).
    В качестве параметров:
    • Выбор целевой базы (это будет почти во всех задачах, потому далее на этот параметр я не буду обращать внимание в пределах этой статьи).
    • Объект, в котором мы выбираем «Таблицы и представления».
    • Параметры свободного места – при малом объеме жесткого диска можно выбирать пункт «по умолчанию», однако я рекомендую использовать «Изменить долю свободного места на странице», рекомендуемое значение 20%. Это позволит оставить запас свободных страниц, и позволит дольше держать индексы в актуальном состоянии. ВНИМАНИЕ: Увеличивает размер базы данных.
    • Отсортировать результаты в tempdb. Думаю пояснять не требуется, однако предупредить хочу, в это время tempdb, будет очень сильно разрастаться, хоть и сортировка в ней и призвана ускорить процесс, будьте осторожны, имейте запас пространства.
    • Сохранять индекс в режиме «в сети» - фишка доступная для enterprise версии SQL. Позволяет делать переиндексацию без отключения клиентов.

    !!! ВНИМАНИЕ!!! В Standard версии при переиндексации происходит отключение клиентов от базы данных на время работы данного шага.

    Пример настроек


  2. Обновление статистики. Задача сбора информации о состоянии индексов в базе. (В общем-то мало актуальная после переиндексации, но все же я делаю).
    Параметры:
    • Объект. Все те же таблицы и представления, что и для перестроения индекса.
    • Обновить. Тут обновляем всю статистику.
    • Тип просмотра – Полный просмотр.

    Таким образом, мы обновляем статистику по всей базе данных.

    Пример настроек


  3. Выполнение инструкции T-SQL. Это выполнение произвольной команды на языке SQL, в частности нас интересует dbcc proccache

    Как следует из название – чистка кэша.

    Пример


  4. Проверка целостности базы данных. Тут кажется излишни пояснения – убеждаемся, что ничего не сломалось. В параметрах «включаем индексы» в проверку, не зря же перестраивали.

    Пример настроек


  5. Резервное копирование базы данных. Тут поговорить надо побольше, ввиду многих особенностей. Лучше изучить данный пункт отдельно самостоятельно в других руководствах, формат данной статьи не предусматривает углубленного изучения резервного копирования.
    Но о паре нюансов хочу предупредить:
    • SQL не умеет чистить контейнер свой, потому если добавлять резервные копии в файл (оно же обзывается «Устройство резервного копирования»), в итоге забьете все свободное место.
    • SQL помнит о своих резервных копиях, потому сделав ручками бэкап, единоразовый (например, отнести базу в другое место, или чтоб развернуть для теста в еще одну базу из бэкапа), следующий «разностный» будет отсчитываться от него. Дабы предотвратить это, требуется ставить галочку «Только резервное копирование». В задаче резервного копирования такого пункта нет. Вообще в недельном плане рекомендую все же использовать полный тип резервной копии.
    • И хорошо бы проверять копию, пусть спиться спокойнее.
    • Сжатие, в общем-то, использовать можно, но будьте аккуратны, разностные тогда надо тоже сжимать.

    Пример настроек

  6. Очистка журнала.
    • Журнал резервного копирования и восстановления.
    • Журнал заданий агента SQL Server.
    • Журнал плана обслуживания.

    Я чищу все. Как следует из названия, чистит события в журнале SQL. Я считаю, что события старше 4 недель вряд ли меня заинтересуют, ибо если проблема есть, то о ней сообщать в течение месяца.

    Пример настроек


  7. Уведомление оператора. Пунктик опять-таки для самостоятельного изучения. Но как понятно из названия, для сообщения о проблемах в ходе выполнения плана.

Daily

Общий вид

Говорить отдельно не имеет смысла. Почти все аналогично Weekly.
Различие в первой задаче – «Реорганизации индексов». Задачи отличаются тем, что реорганизация пытается выправить имеющиеся индексы, а не делает все с чистого листа. Чем больше фрагментация – тем чаще стоить запускать. Но в нормальных условиях раз в день достаточно, чтобы поддерживать индекс в актуальном состоянии до следующего перестроения.

Параметры


Так же можно использовать разностное резервное копирование.

На этом все. Повторяюсь, догматов в этом моменте я не видел, этот вариант был разработан и протестирован мной. Актуально для баз размером от 6 до 100 ГБ.

Желаю Вам быстрой и надежной работы.
P.S. В силу того что не являюсь полноценным DBA, возможно мои комментарии весьма поверхностны, с удовольствием прочту замечания в комментариях и личке.

В SQL Server 2016 и более поздних версиях можно установить все компоненты, связанные с Службы R Services (в базе данных), с помощью мастера установки SQL Server.

По завершении установки могут потребоваться дополнительные действия, чтобы включить службы R, настроить учетные записи и предоставить пользователям разрешения на доступ к определенным базам данных.

Если после завершения установки возникают проблемы с доступом к базам данных или если необходимо удалить предыдущие версии, см. раздел .

    Откройте среду SQL Server Management Studio. Если она еще не установлена, вы можете повторно запустить мастер установки SQL Server, чтобы скачать ее по ссылке и установить.

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

    Exec sp_configure "external scripts enabled" , 1 Reconfigure with override

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

    После того как служба SQL Server станет доступна, проверьте, включен ли компонент R, выполнив следующую команду и проверив, имеет ли свойство run_value значение 1:

    Exec sp_configure "external scripts enabled"

    Вы также можете открыть панель Службы и проверить, работает ли служба панели запуска для вашего экземпляра. Каждый экземпляр имеет собственную службу панели запуска.

    Теперь у вас должна быть возможность выполнять в SQL Server Management Studio простые скрипты R, наподобие следующего:

    Exec sp_execute_external_script @language =N"R", @script=N"OutputDataSet <-InputDataSet ", @input_data_1 =N"select 1 as hello" with result sets (( int not null)); go

    Результаты

    hello
    1

В процессе установки создаются 20 учетных записей пользователей Windows в целях выполнения задач с токеном безопасности службы Доверенная панель запуска SQL Server. Когда пользователь отправляет скрипт R из внешнего клиента, SQL Server активирует доступную рабочую учетную запись, сопоставляет ее с удостоверением вызывающего пользователя и выполняет скрипт R от имени пользователя. Это новая служба ядра СУБД, которая обеспечивает безопасное выполнение внешних скриптов с помощью механизма, называемого неявной проверкой подлинности .

Учетные записи можно просмотреть в группе пользователей Windows SQLRUserGroup . Если вам нужно выполнять скрипты R из удаленного клиента обработки и анализа данных и вы используете проверку подлинности Windows, этим рабочим учетным записям необходимо предоставить разрешение на вход в экземпляр SQL Server от вашего имени.

  1. В среде SQL Server Management Studio в обозревателе объектов разверните узел Безопасность , щелкните правой кнопкой мыши Имена входа и выберите пункт Создать имя входа .
  2. В диалоговом окне Создание имени входа нажмите кнопку Поиск .
  3. Щелкните Типы объектов и выберите пункт Группы . Отмените выбор всех остальных пунктов.
  4. В поле "Введите имя объекта" введите SQLRUserGroup и щелкните Проверить имена .
  5. Имя локальной группы, связанной со службой панели запуска экземпляра, должно разрешиться в имя_экземпляра\SQLRUserGroup . Нажмите кнопку ОК .
  6. По умолчанию имя входа назначается общедоступной роли и имеет разрешение на подключение к ядру СУБД.
  7. Нажмите кнопку ОК .

Если вы установили SQL Server самостоятельно и выполняете скрипты R в собственном экземпляре, то, как правило, делаете это с правами администратора и поэтому имеете явное разрешение на совершение различных операций и доступ ко всем данным в базе данных, а также возможность устанавливать новые пакеты R по мере необходимости.

Но в корпоративном сценарии большинство пользователей, включая тех, которые обращаются к базе данных с помощью имен входа SQL, не имеют таких повышенных прав. Поэтому каждому пользователю, который будет выполнять внешние скрипты, необходимо предоставить разрешения на выполнение скриптов R в каждой базе данных, в которой будет использоваться R.

USE GO GRANT EXECUTE ANY EXTERNAL SCRIPT TO

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

Изменение числа рабочих учетных записей, используемых Доверенная панель запуска SQL Server

Если вы предполагаете, что будете интенсивно использовать среду R или множество пользователей будут одновременно выполнять скрипты, вы можете увеличить количество рабочих учетных записей, назначенных службе панели запуска. Дополнительные сведения см. в разделе .

Предоставление пользователям или именам входа R необходимых разрешений на чтение, запись или DDL в дополнительных базах данных

При выполнении скриптов R учетной записи пользователя может потребоваться считывать данные из других баз данных, создавать таблицы для хранения результатов и записывать данные в таблицы.

Каждая четная запись пользователя, выполняющая скрипты R, должна иметь разрешения db_datareader , db_datawriter или db_ddladmin для определенной базы данных.

Например, приведенная ниже инструкция Transact-SQL предоставляет имени входа SQL MySQLLogin права на выполнение запросов T-SQL в базе данных RSamples . Для выполнения этой инструкции имя входа SQL уже должно существовать в контексте безопасности сервера.

USE RSamples GO EXEC sp_addrolemember "db_datareader" , "MySQLLogin"

Дополнительные сведения о разрешениях, включенных в каждую роль, см. в разделе .

Создание источника данных ODBC для экземпляра в клиенте обработки и анализа данных

Если вы создаете решение R на клиентском компьютере обработки и анализа данных и вам необходимо подключаться к компьютеру SQL Server, который служит контекстом вычисления, вы можете использовать имя входа SQL или встроенную проверку подлинности Windows.

При использовании имени входа SQL оно должно иметь соответствующие разрешения на доступ к базе данных, из которой будут считываться данные. Для этого можно добавить разрешения Подключиться к и SELECT или добавить имя входа к роли db_datareader . Если вам нужно создавать объекты, вам потребуются права DDL_admin . Чтобы сохранять данные в таблицах, добавьте имя входа к роли db_datawriter .

При использовании проверки подлинности Windows необходимо настроить источник данных ODBC в клиенте обработки и анализа данных, указав имя экземпляра и другие сведения о подключении.

Дополнительные сведения см. в разделе .

Оптимизация сервера для R

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

Чтобы задачам R назначались соответствующие приоритеты и выделялись необходимые ресурсы, рекомендуем использовать средство Resource Governor с целью настройки внешнего пула ресурсов для операций R. Кроме того, можно изменить размер памяти, выделенный ядру СУБД SQL Server, или увеличить количество учетных записей в службе Доверенная панель запуска SQL Server.

    Совместимо с версией RC2: скачать архив rre-gpl-src.8.0.2.tar.gz

    Совместимо с версией RC3: скачать архив rre-gpl-src.8.0.3.tar.gz

    Совместимо с версией RTM: скачать архив rre-gpl-src.8.0.3.tar.gz

Возникли проблемы? Ознакомьтесь со списком распространенных проблем при установке предварительных версий Службы R Services (в базе данных).

Достаточно нередко у разработчиков клиент-серверных приложений возникает необходимость организовать некий механизм, позволяющий по событию на sql-сервере уведомить того или иного клиента. Ещё чаще это является розово-голубой мечтой заказчика, чтобы разработчик реализовал такой механизм. Например, при превышении лимитов отгрузки какому-либо потребителю, должны быть немедленно уведомлены менеджеры, работающие с этим потребителем. Некоторые заказчики систем требуют (а мечтают об этом все заказчики без исключения), чтобы при изменении каких-то данных, у остальных пользователей системы эта информация автоматически обновлялась, причем незамедлительно. Здесь не будет обсуждаться целесообразность такого требования (оно имеет много оснований для критики), здесь будут обсуждаться только пути решения. microsoft sql-сервер имеет штатное средство для организаций уведомлений — alerts, но это средство имеет весьма ограниченное применение, по большому счету не дающее возможность создать на его основе гарантированно работающий механизм. И вот почему: Связь с клиентской программой может быть осуществлена путем посылки e-mail или эмуляцией посылки "net send". И то, и другое неудобно для получения уведомления.

Средство e-mail неудобно по причинам:

a) нет гарантии доставки, почта может теряться.
b) почта может "застрять" на промежуточных узлах.
c) требуется обязательно наличие протокола tcp/ip
d) требуется наличие smtp-сервера и настройка почтового профиля.
e) требуется особая настройка sql-сервера, чтобы он смог посылать письма.
f) требуется наличие у каждого клиента, ждущего события, почтового ящика.
g) в клиентской программе требуется организовать почтовый клиент.

Посылка путем «net send» неудобна по следующим причинам:

a) нет гарантии доставки, так как это организовано через средство mailslot, не имеющее такой гарантии.
b) требуется наличие корректного разрешения имен netbios в сети.
c) требуется наличие на клиенте "Клиент для сетей Микрософт".
d) задействован стандартный mailslot, это может иметь пересечение с другими программами.

И в целом средство alerts неудобно необходимостью регистрации каждого клиента в качестве оператора и соответствующей настройкой. Т.е. для простейших случаев alerts применить можно. Но для большинства случаев оно неприменимо.

Известные реализации и концепции

Широкой общественности известны несколько вариантов реализации механизма уведомления сервером клиента. Это:

1. Создание объекта (extended stored procedure или activex), посредством которого sql-сервер уведомляет клиента через сокеты tcp/ip. При этом на клиенте организована прослушка, т.е. клиентская программа стала сервером tcp/ip.
Недостатки этого метода:
a) Привязка к протоколу tcp/ip. В сети, где используется только ipx, netbeui или appletalk, такой механизм не применить.
b) Нет асинхронности. Если это событие генерируется из триггера, будут проблемы производительности.

2. Создание объекта (extended stored procedure или activex), посредством которого sql-сервер уведомляет клиента через named pipes или mailslots. При этом на клиенте организована прослушка того или другого.
Недостатки этого метода:
a) требуется наличие корректного разрешения имен netbios в сети.
b) требуется наличие на клиенте "Клиент для сетей Микрософт".
c) в случае использования mailslot нет гарантии доставки.
d) в случае использования named pipes, это нельзя применить на клиентских компьютерах с операционной системой windows 95/98/me, так как named pipe можно создать только в операционной системе на архитектуре nt.
e) Нет асинхронности. Если это событие генерируется из триггера, будут проблемы производительности.

3. Периодический опрос sql-сервера клиентом (периодическое чтение специальной таблички евентов). Это очень простой путь, но, тем не менее, свободный от большинства вышеперечисленных недостатков. К сожалению, этот метод имеет свои специфичные 2 недостатка: a) получение уведомления может быть задержано на величину таймаута опроса и b) при маленьком таймауте возникает существенный трафик. Тем не менее, при небольшом кол-ве сессий, этот метод вполне пригоден и незаслуженно обойден вниманием.

Предлагаемый вариант решения

Вашему вниманию предлагается вариант решения проблемы, свободный от вышеперечисленных (всех вышеперечисленных!) проблем, но вместе с тем достаточно простой. Идея такова: на сервер помещается некий двоичный объект, который sql-сервер может вызывать (а это может быть только extended stored procedure или activex-объект), имеющий два невзаимосвязанных метода.
Первый метод создает с помощью функции win32api createevent объект ядра win32, именуемый "event" с уникальным наименованием, переданным параметром. Далее вызывается функция win32api waitforsingleobject, наткнувшись на которую, поток останавливается и стоит в ожидании, пока этот объект ядра не засигналит. Обращаю ваше внимание, на тот факт, что таких объектов ядра может быть создано сколько угодно. Это ограничено только кол-вом хендлов в системе.
Второй метод вызывает объект ядра event по имени, заданным параметром, с помощью функции win32api setevent и выставляет ему свойство "signaled". Как только это произойдет, поток с первым методом пробуждается и возвращает управление вызвавшему процессу. Второй метод, не ожидает результата, а возвращает управление своему вызвавшему процессу сразу же после выставления свойства "signaled". Таким образом достигается асинхронность.
Теперь остается только сделать хранимые процедуры t-sql, управляющие этим объектом и нужная функциональность "у нас в кармане". Клиентская программа в отдельном потоке запускает хранимую процедуру ожидания события, передавая параметром уникальный признак-адрес. Это может быть и имя пользователя, и имя компьютера, и любая строка. Главное, чтобы это была уникальный идентификатор в пределах клиент-серверной системы. Хранимая процедура вернет результат только в случае, если для этого адресата будет сгенерировано событие. При получении события, процедура перезапускается. При закрытии программы поток ожидания события просто прибивается через terminatethread.
На первый взгляд эта метода обладает "ужасным" недостатком — существует постоянный коннект с sql-сервером, который большую часть времени ничего не делает. Но это только первое впечатление. На самом деле, задействуются ресурсы здесь только на поддержание коннекта — это что-то несколько килобайт на сессию. И все! Больше никаких осязаемых ресурсов не тратиться, особенно на фоне преимуществ, которые описаны ниже. О дополнительных лицензиях можно тоже не беспокоиться, если выбрана модель лицензирования "per server". В этом случае с одной машины может быть сколько угодно коннектов к sql-серверу, это все равно будет занимать ровно одну клиентскую лицензию.

Готовое решение

Решение состоит из activex-объекта в виде файла algoevt.dll и двух хранимых процедур spwaitforevent и spraiseevent. Перед использованием этот файл надо поместить на сервер и зарегистрировать activex-объект с помощью системной утилиты regsvr32.exe. Дальше вся работа будет производиться через хранимые процедуры. В готовом решении реализована несколько бОльшая функциональность, чем в описанной концепции. Кроме самого факта события, можно передать также произвольную информацию в виде строки в размере до 250 символов. Каждая процедура имеет два параметра. Первая — это уникальный идентификатор-адрес, о котором говорилось выше, а второй параметр — дополнительная передающаяся информация. spwaitforevent надо вызвать с клиента из отдельного потока (приоритет потока можно выбрать самый низкий). При получении события, процедуру надо перезапустить. Тайм-аут исполнения запроса надо задать бесконечный.



Рекомендуем почитать