Получение уведомлений ms sql сервера в с builder


Содержание

Настройка Database Mail в SQL Server 2008

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

Мастер настройки Database Mail.

Настройка компонента Database Mail выполняется в Среде Microsoft SQL Server Management Studio. Раскрываем папку «Управление» и находим «Компонент Database Mail». Щелкаем по компоненту правой клавишей мыши и в контекстном меню выбираем пункт «Настроить компонент Database Mail«

Запустится мастер настройки компонента. При первом запуске необходимо выбрать первый пункт мастера «Установить компонент Database Mail…». Второй пунктом будем пользоваться, если необходимо изменить существующие учетные записи и профили.

Создаем новый профиль.

На этапе создания вводим Имя профиля и при необходимости добавляем описание. Нажимаем кнопку «Добавить» для создания учетной записи почтового сервера SMTP.

Добавляем учетную запись SMTP

Заполняем все необходимые поля. Обязательно указываем:

  • Имя учетной записи;
  • Адрес электронной почты;
  • Имя сервера;
  • Номер порта;
  • Имя пользователя: вводится вместе с адресом домена, как почтовый адрес;
  • пароль.

Дополнительные поля, которые не обязательны, но добавляют информативности:

  • Описание: комментарий к учетной записи;
  • Отображаемое имя: это имя отправителя, которое будет показано в сообщении. Для наглядности можно написать имя сервера, с которого пришло сообщение.

Если планируете использовать учетную запись сервера исходящей почты smtp.mail.ru обратите внимание на несколько важных пунктов:

  • номер порта 587
  • Для данного сервера требуется безопасное соединение (SSL)

Mail.ru и многие публичные почтовые серверы используют протокол шифрования, поэтому стандартный 25 порт не подходит. На сайте mail.ru в качестве порта для протокола шифрования указан 465, но если вы укажите этот порт, то сообщения отправляться не будут. А в журнале будет фиксироваться сообщение с ошибкой: «Почту не удалось доставить получателям из-за сбоя почтового сервера. (Отправка сообщения через учетную запись 1 (2020-01-11T09:39:07). Сообщение об исключении: Не удается послать сообщения на почтовый сервер. (Время ожидания операции истекло.).

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

Управление безопасностью профилей.

Следующим шагом настройки будет «Управление безопасностью профилей». Здесь созданный профиль можно указать в качестве открытого по умолчанию.

На вкладке «Личные профили» есть возможность указать отдельные профили для конкретного пользователя. В моем случае в этом нет необходимости.

Установка системных параметров

В установке системных параметров можно настроить файловые вложения к почтовым сообщениям и количество попыток отправки. Я оставлю параметры так как есть.

Завершение мастера настройки

На шаге «Завершения мастера настройке» будут показаны запланировнные действия. Жмем готово, закрываем отчет и переходим к отправке тестового сообщения.

Отправка тестового сообщения

В контекстном меню компонента Database Mail выбираем «Отправка тестового сообщения» указываем свой адрес электронной почты и жмем отправить.

Если сообщения пришло значит все сделано правильно и можно приступить к добавлению операторов, если нет — открываем журнал компонента Database Mail, наливаем чашку крепкого кофе и долго чешем репу.

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

Добавление оператора MS SQL

Раскрываем объект «Агент SQL Server» и находим папку «Операторы«. Выбираем из меню пункт «Создать оператора«

Указываем имя и адрес почты на которые будут приходить уведомления от SQL Server. Жмем «ОК» и оператор создан.

Приступаем к настройке уведомлений задания.

Настройка уведомлений задания.

Открываем свойства выбранного задания SQL Server.

Переходим на страницу «Уведомления» отмечаем пункт «Электронная почта» и выбираем оператора. Указываем какой тип уведомлений хотим получать по почте.

3.7. Предупреждения MS Sql Server

Предупреждения (Alert или я еще люблю говорить Тревога) позволяют контролировать работу вашего сервера. Вы можете создавать тревоги на определенные события сервера (ошибки данных, ошибки запросов, ошибки или удачные выполнения работ и т.д.) и направлять сообщения определенным операторам. Когда мы создавали работы, то для них автоматически создаются тревоги, если указан оператор, который должен получать информацию об удачном или не удачном выполнении работы.

Благодаря тревогам, администратор может сидеть в нескольких тысячах километров от SQL сервера. Если произойдет внештатная ситуация, то администратор получит e-mail сообщение и сможет подключиться к серверу и исправить ошибку. Без тревоги, администратору пришлось бы постоянно контролировать работу сервера и наблюдать за большим количеством параметров.

Планировщики, как и работы, выполняются сервисом SQL Service Agent, поэтому он должен быть запущен, желательно, чтобы он запускался автоматически после загрузки ОС.

3.7.1. Создание сообщений

Для создания собственных сообщений (message) используется процедура SQL сервера sp_addmessage. В общем виде эта процедура выглядит следующим образом:

Параметров не так уж и много, поэтому давайте рассмотрим их, прежде чем напишем реальный пример:

  1. Номер (идентификатор) сообщения, который должен начинаться с 500001;
  2. Уровень критичности. К нему предъявляются такие же правила, как и у функции RAISERROR;
  3. Текст сообщения, максимальный размер которого 255 символов;
  4. Язык сообщения. По умолчанию используется нулевое значение и язык, установленный в системе;
  5. Нужно ли писать о событии в журнал сообщений Windows. Если в этом параметре указано true, то в журнал будет записано сообщение об ошибке. Если false, сообщение не обязательно будет записано в журнал, тут уже все зависит от того, как оно было сгенерировано;
  6. Если сообщение с указанным номером существует, то в этом параметре можно указать команду REPLACE. Это означает, что существующую ошибку с указанным номером надо заменить.

Давайте создадим свое сообщение:

Чуть позже мы увидим, как воспользоваться сообщениями.

Давайте рассмотрим, как можно удалять сообщения. Для этого используется процедура sp_dropmessage:

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

3.7.2. Создание предупреждения

Для создания предупреждения (alert) используется процедура sp_add_alert, которая выглядит следующим образом:

Рассмотрим доступные параметры этой процедуры:

  • @name – имя тревоги, которое должно быть уникальным и по нему система будет в дальнейшем идентифицировать тревогу;
  • @message_id – номер ошибки, на которую должно реагировать тревога. В MS SQL Server предопределено достаточно много ошибок, на которые вы можете создать тревоги. Чтобы увидеть их, просмотрите таблицу sysmessages в базу данных master:

В разделе 3.7.1 мы увидели, как создавать собственные сообщения ошибок.

  • @severity – число от 1 до 25, определяющее уровень критичности торевоги. Если вы указали параметр @message_id, то параметр @severity должен быть равен нулю;
  • @enabled – если параметр равен 1, то тревога является активной, иначе (если равно нулю) оно не будет генерироваться и операторы не получат уведомление;
  • @delay_between_responses – задержка в секундах между событием и действием на это событие. В качестве действия может быть одно или более уведомлений на E-mail или пейджер оператора или выполнение определенной работы. По умолчанию задержки нет (значение 0) и действие произойдет сразу после генерации тревоги;
  • @notification_message – в этом параметре вы можете задать дополнительный текст тревоги, которое будет добавлено к сообщению, отправляемому оператору;
  • @include_event_description_in – параметр определяет, куда необходимо добавлять сообщение тревоги. В этом параметре можно указывать одно из следующих значений (или сумму):
    • 0 – никуда;
    • 1 – к e-mail сообщению;
    • 2 – к сообщению на пейджер;
    • 4 – к сообщению, отправляемому net send.

Например, если вы хотите, чтобы текст добавлялся к e-mail сообщению и к сообщению NET SEND, то необходимо указать число 5 (сумма чисел 1 и 4);

  • @database_name – в этом параметре можно задать базу данных. Если этот параметр не задан, то сообщение будет генерироваться для всех баз данных;
  • @job_id – позволяет задать идентификатор работы, которая должна выполняться в ответ на тревогу. Если этот параметр указан, то нельзя указывать @job_name;
  • @job_name — позволяет задать имя работы, которая должна выполняться в ответ на тревогу. Если этот параметр указан, то нельзя указывать @job_id;
  • @raise_snmp_trap – не используется;
  • @performance_condition – тревоги могут создаваться для параметров производительности, например, генерация сообщения в случае превышения сервером загрузки в 90%. Если вы создаете такое сообщение, то в этом параметре вы можете указать параметр, условие и значение. В качестве параметра может использоваться объект производительности, счетчик производительности или имя экземпляра счетчика. В качестве условия могут быть знаки больше, меньше или равно. Значение – это числовое значение счетчика;
  • @category_name – имя категории тревоги;

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

Давайте добавим собственное предупреждение или как уже много раз называл эту штуку — тревогу:

В данном примере мы создаем тревогу с названием ‘Тестовая тревога’, которая будет реагировать на сообщение с номером 60001. Сообщение с таким номером было создано нами в разделе 3.7.1.

Теперь посмотрим, как создать тревогу для уже существующих сообщений. В таблице sysmessages базы данных master я нашел сообщение с номером 9002, которое генерируется в случае, если файл журнала полный. Давайте рассмотрим, как с помощью тревоги и работы можно решить классическую задачу с увеличения файла базы данных и очисткой журнала.

Как мы уже знаем, файлы базы данных и файлы журналов могут увеличиваться бесконечно, но это далеко не всегда удобно. Многие администраторы хотят контролировать выделяемое сервером дисковое пространство, поэтому отказываются от автоматического увеличения. Для журнала транзакций можно не увеличивать размер файла, а уменьшать его очисткой. Получается, что наша задача отловить создать тревогу, которая будет реагировать на переполнение журнала и запускать работу очистки журнала. Это можно сделать следующим образом:

Теперь создадим работу, которая будет очищать журнал. Да, мы еще не рассматривали резервное копирование, которое необходимо для решения данной задачи и данная тема будет рассмотрена в 4-й главе. Если вы не знакомы с этими командами, то не обращайте внимания на операторы Transact-SQL. Вернитесь к ним после прочтения 4-й главы. Сейчас наша задача создать работу, а заодно лишний раз потренироваться и закрепить пройденный материал на практике. Итак, работу и два шага выполняющих резервирование и обрезание журнала вы можете увидеть в листинге 3.9.

Листинг 3.9. Создание работы из 2-х шагов резервирования журнала

Сообщение 9002 является критичным и генерируется, когда журнал уже полный и сервер не смог сохранить в нем информацию о транзакции. Если нет автоматического увеличения, то серверу негде будет хранить информацию о транзакции и такая транзакция откатывается, а значит, данные не будут сохранены. Так будет со всеми последующими транзакциями, пока в журнале не появиться свободное пространство, поэтому данный метод увеличения журнала нельзя назвать эффективным, потому что с момента переполнения журнала до момента освобождения пространства в журнале сервер будет доступен только для чтения. Именно поэтому, освобождением должна заниматься работа, которая должна выполняться мгновенно, без задержек и не ждите, пока в работу сервера не вмешается администратор, который в этот момент может спать.

Файл данных просто так обрезать не получиться. Вы же не можете просто так удалить все данные из таблиц и начать их заполнять с нуля. В этом случае, увеличение должно происходить, но все же может быть работа, которая будет делать увеличения с помощью Transact-SQL запроса и выделять пространства там, где прописано в сценарии администратором.

Обновление

Для обновления тревоги используется процедура sp_update_alert. У этой процедуры такие же параметры, как и у процедуры создания тревоги sp_add_alert. Общий вид достаточно большой, потому что содержит достаточно много параметров, и ради экономии места мы не будем рассматривать общий вид.

Для удаления тревоги используется процедура sp_delete_alert, которой нужно передать в качестве параметра только имя удаляемой тревоги, например, так:

Получение информации

Для получения информации о тревогах, используется процедура sp_help_alert, которая выглядит следующим образом:

У этой процедуры четыре параметра и все они являются не обязательными. Давайте рассмотрим каждый параметр:

  • @alert_name – имя сообщения, информацию о котором, необходимо получить;
  • @order_by – отсортировать список по определенному параметру;
  • @alert_id – идентификатор сообщения, информацию которого необходимо определить;
  • @category_name – имя категории.
Илон Маск рекомендует:  Описание форматов звуковых файлов выборок

Если выполнить процедуру sp_help_alert без параметров, то результатом будут все тревоги SQL сервера:


Результатом будет таблица, состоящая из полей, которые идентичны по имени и назначению параметрам, которые мы рассматривали у процедуры добавления тревоги sp_add_alert.

Отобразим тот же список, но отсортируем результирующий список по параметру message_id:

3.7.3. Создание уведомления

У нас есть тревога и есть сообщение. Для создания уведомления необходимо связать эти два объекта, чтобы в ответ на тревогу генерировалось сообщение и направлялось оператору. Такую связь можно назвать уведомлением и для его создания используется процедура sp_add_notification, которая выглядит следующим образом:

Здесь у нас три параметра:

  • @alert_name – имя тревоги;
  • @operator_name – имя оператора, который должен получать уведомление;
  • @notification_message – метод, которым оператор будет получать уведомления об ошибке:
    • 1 – на e-mail адрес;
    • 2 – на пейджер;
    • 4 – командой NET SEND.

Может быть несколько методов получения уведомления. Для этого в параметре @notification_message нужно указать сумму значений методов. Например, если нужно информировать оператора по e-mail и на пейджер, то в параметре @notification_message указываем значение 3 (1+2).

Примеры использования

Прежде чем создавать уведомление добавим оператора:

Чтобы наглядно увидеть результат работы, я задал IP адрес своего компьютера, чтобы получать NET SEND сообщение.

Следующий пример показывает, как создать уведомление, которое будет получать администратор для тревоги, созданной в разделе 3.7.2:

Одна тревога может направлять сообщения нескольким операторам. Следующий пример добавляет уведомление еще одного оператора для тревоги с именем ‘Тестовая тревога’:

Вот теперь вы можете увидеть результат работы на примере. Для этого необходимо сгенерировать сообщение с помощью функции RAISERROR (более подробно о RAISERROR мы поговорим в разделе 4.3.2):

В ответ на это, я получил NET SEND сообщение.

Если вы используете NET SEND сообщения, то убедитесь, что в вашей ОС запущен сервис Messenger, без которого отправка сообщения будет невозможной.

Обновление

Для обновления уведомления используется процедура sp_update_notification, которая выглядит следующим образом:

Параметры такие же, как и при создании уведомления sp_add_notification, только параметр @alert_name определяет тревогу, которую надо обновить, а параметр @operator_name определяет оператора. С помощью параметра и @notification_method можно задать новый метод уведомления.

Удаление

Для удаления уведомления используется процедура sp_delete_notification, которая в общем виде выглядит следующим образом:

Параметр @alert_name определяет тревогу, которую надо удалить, а параметр @operator_name определяет удаляемого оператора.

Как настроить и запустить Microsoft SQL Server

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

MS SQL Server

Данный программный продукт представляет собой систему управления базами данных ( СУБД ) реляционного типа, разработанную корпорацией Microsoft . Для манипуляции данными используется специально разработанный язык Transact-SQL . Команды языка для выборки и модификации базы данных построены на основе структурированных запросов:

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

Обзор возможностей MS SQL Server

СУБД является частью длинной цепочки специализированного программного обеспечения, которое корпорация Microsoft создала для разработчиков. А это значит, что все звенья этой цепи ( приложения ) глубоко интегрированы между собой.

То есть их инструментарий легко взаимодействует между собой, что во многом упрощает процесс разработки и написания программного кода. Примером такой взаимосвязи является среда программирования MS Visual Studio . В ее инсталляционный пакет уже входит SQL Server Express Edition .

Конечно, это не единственная популярная СУБД на мировом рынке. Но именно она является более приемлемой для компьютеров, работающих под управлением Windows, за счет своей направленности именно на эту операционную систему. И не только из-за этого.

Преимущества MS SQL Server :

  • Обладает высокой степенью производительности и отказоустойчивости;
  • Является многопользовательской СУБД и работает по принципу « клиент-сервер »;

Клиентская часть системы поддерживает создание пользовательских запросов и их отправку для обработки на сервер.

  • Тесная интеграция с операционной системой Windows ;
  • Поддержка удаленных подключений;
  • Поддержка популярных типов данных, а также возможность создания триггеров и хранимых процедур;
  • Встроенная поддержка ролей пользователей;
  • Расширенная функция резервного копирования баз данных;
  • Высокая степень защищенности;
  • Каждый выпуск включает в себя несколько специализированных редакций.
  • Эволюция SQL Server

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

    • Microsoft SQL Server 1.0 – вышел еще в 1990 году. Уже тогда эксперты отмечали высокую скорость обработки данных, демонстрируемую даже при максимальной нагрузке в многопользовательском режиме работы;
    • SQL Server 6.0 – вышел в 1995 году. В этой версии впервые в мире была реализована поддержка курсоров и репликации данных;
    • SQL Server 2000 – в этой версии сервер получил полностью новый движок. Большая часть изменений коснулась лишь пользовательской стороны приложения;
    • SQL Server 2005 – увеличилась масштабируемость СУБД , во многом упростился процесс управления и администрирования. Был внедрен новый API для поддержки программной платформы .NET ;
    • Последующие выпуски – были направлены на развитие взаимодействия СУБД на уровне облачных технологий и средств бизнес-аналитики.

    В базовый комплект системы входит несколько утилит для настройки SQL Server . К ним относятся:

    • SQL Server Configuration Manager :

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

    • SQL Server Error and Usage Reporting :

    Утилита служит для настройки отправки отчетов об ошибках в службу поддержки Microsoft .

    • SQL Server Surface Area Configuration

    Используется для оптимизации работы сервера базы данных. То есть вы можете настроить функционирование SQL Server под свои нужды, включив или отключив определенные возможности и компоненты СУБД .

    Набор утилит, входящих в Microsoft SQL Server , может отличаться в зависимости от версии и редакции программного пакета. Например, в версии 2008 года вы не найдете SQL Server Surface Area Configuration .

    Запуск Microsoft SQL Server

    Для примера будет использована версия сервера баз данных выпуска 2005 года. Запуск сервера можно произвести несколькими способами:

    • Через утилиту SQL Server Configuration Manager . В окне приложения слева выбираем « SQL Server 2005 Services », а справа — нужный нам экземпляр сервера БД . Отмечаем его и в подменю правой кнопки мыши выбираем « Start ».
    • С помощью среды SQL Server Management Studio Express . Она не входит в инсталляционный пакет редакции Express . Поэтому ее нужно скачивать отдельно с официального сайта Microsoft .

    Для запуска сервера баз данных запускаем приложение. В диалоговом окне « Соединение с сервером » в поле « Имя сервера » выбираем нужный нам экземпляр. В поле « Проверка подлинности » оставляем значение « Проверка подлинности Windows ». И нажимаем на кнопку « Соединить »:

    Основы администрирования SQL Server

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

    • SQL Server Surface Area Configuration – сюда следует обращаться, если нужно включить или отключить какую-либо возможность сервера баз данных. Внизу окна находятся два пункта: первый отвечает за сетевые параметры, а во втором можно активировать выключенную по умолчанию службу или функцию. Например, включить интеграцию с платформой .NET через запросы T-SQL :
    • SQL Server Management Studio – является основным средством администрирования. В этой среде реализована возможность настройки сервера и баз данных, как через интерфейс приложения, так и с помощью запросов на языке T-SQL .

    Основные настройки можно осуществить через « Обозреватель объектов », отображающий слева в окне приложения все основные элементы сервера в виде древовидного списка. Самой важной является вкладка « Безопасность ». Через нее можно настроить права и роли пользователей и администраторов для основного сервера, или отдельно для каждой базы данных:

    Основная часть настроек сервера баз данных доступна в окне « Свойства сервера »:

    Как видите, Microsoft SQL Server является настолько мощным средством для структуризации, хранения и модификации данных, что на его изучение потребуется много времени. А в статье мы лишь слегка углубились в основы сервера SQL .

    Получение уведомлений ms sql сервера в с builder

    В этом разделе описывается настройка в агенте SQL Server использования компонента Database Mail для отправки уведомлений и предупреждений в SQL Server 2020 с помощью среды SQL Server Management Studio. Сведения о включении и настройке компонента Database Mail см. в разделе Настройка компонента Database Mail. Пример использования Transact-SQL см. в разделе Создание профиля компонента Database Mail.

    Перед началом работы выполните следующие действия.

    Настройка агента SQL Server на использование компонента Database Mail с помощью среды SQL Server Management Studio


    Задачи дополнительной работы

    Предварительные требования

    Создать профиль компонента Database Mail для учетной записи агента SQL Server, чтобы сделать пользователя членом роли DatabaseMailUserRole в базе данных msdb.

    Сделать профиль используемым по умолчанию в базе данных msdb .

    Безопасность

    Разрешения

    Пользователь, создающий учетные записи профилей и выполняющий хранимые процедуры, должен быть членом предопределенной роли сервера sysadmin.

    Настройка агента SQL Server на использование компонента Database Mail

    Разверните экземпляр сервера SQL Server в обозревателе объектов.

    Щелкните правой кнопкой мыши агент SQL Server, затем выберите Свойства.

    Нажмите Система предупреждений.

    Выберите Включить почтовый профиль.

    В списке Почтовая система выберите Компонент Database Mail.

    В Списке почтовых профилейвыберите почтовый профиль для компонента Database Mail.

    Перезапустите агент SQL Server.

    Следующие задачи необходимо выполнить для завершения конфигурации агента на отправку предупреждений и уведомлений.

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

    Операторы — это псевдонимы для людей или групп, которые могут получать электронные уведомления.

    Получение уведомлений ms sql сервера в с builder

    Обновлено: November 1, 2012

    Применимо к: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

    В этом разделе описывается создание пользовательского отчета с OLAP-кубом в качестве источника данных. Для выполнения описанных в этом разделе процедур требуется доступ к Report Builder, являющемуся компонентом Службы Microsoft SQL Server Reporting Services.

    Дополнительные сведения о Report Builder и осуществлении доступа к нему см. в документации по Сервер SQL.

    Если Службы Reporting Services выполняется в штатном режиме, выполните следующие действия, чтобы открыть Report Builder с веб-сайта диспетчера отчетов.

    Перейдите на веб-сайт диспетчера отчетов. По умолчанию URL-адрес имеет следующий вид: http://[SSRSServerName]:80/Reports.

    Нажмите кнопку Report Builder .

    Открывается Report Builder, в котором отображается мастер «Приступая к работе», с помощью которого можно создать отчет. Сведения о создании отчета с использованием мастера «Приступая к работе» см. в следующем разделе этой темы.

    Если Службы Reporting Services выполняется в режиме интеграции с SharePoint, выполните следующие действия, чтобы открыть Report Builder с сайта SharePoint.

    Перейдите на веб-сайт SharePoint.

    Перейдите к библиотеке документов, которая содержит отчеты Microsoft Dynamics AX.

    Перейдите на вкладку Документы .

    Щелкните Создать документ > Отчет Report Builder .

    Если параметр Отчет Report Builder недоступен, ваш системный администратор может добавить тип содержимого Report Builder в библиотеку документов. Этот процесс описан в разделе Добавление типов содержимого сервера отчетов в библиотеку (службы Reporting Services в режиме интеграции с SharePoint) в документации SQL Server.

    Открывается Report Builder, в котором отображается мастер «Приступая к работе», с помощью которого можно создать отчет. Сведения о создании отчета с использованием мастера «Приступая к работе» см. в следующем разделе этой темы.

    При открытии Repor Builder отображается мастер «Приступая к работе». Этот мастер помогает создать отчет. Выполните следующие действия в мастере.

    На первой странице мастера «Приступая к работе» щелкните Создать отчет , а затем выберите тип отчета, который требуется создать. Данная процедура описывает создание таблицы или матричного отчета.

    На странице Выбор набора данных щелкните Создать набор данных . Щелкните Далее .

    На странице Выбор подключения к источнику данных щелкните Создать .

    В окне Свойства источника данных выполните следующие действия:

    В поле Имя введите имя источника данных.

    Из списка Выбор типа подключения выберите Службы Microsoft SQL Server Analysis Services .

    В окне Свойства подключения выполните следующие действия:

    В поле Имя сервера введите имя сервера, на котором выполняется Analysis Services.

    Из списка Выберите или введите имя базы данных выберите базу данных, содержащую кубы Microsoft Dynamics AX. По умолчанию имя этой базы данных — Dynamics AX или Dynamics AX initial .

    Нажмите кнопку OК .

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

    Повторно отобразится страница Выберите подключение к источнику данных . Щелкните Далее .

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

    Например, чтобы создать отчет, показывающий баланс по каждому счету ГК, потребуется выполнить следующие действия:

    Выберите Куб ГК .

    Разверните узел Измерения > Проводки ГК . Затем перетащите измерение Сумма ГК — валюта учета на поверхность проектирования.

    Разверните узел План счетов . Затем перетащите аналитику Тип и номер счета на поверхность проектирования.

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

    Например, чтобы продолжить пример, описанный в предыдущем шаге, потребуется выполнить следующие действия:

    Перетащите поле Тип_счета в область Группы строк .

    Перетащите поле Имя_основного_счета в область Группы строк .

    Перетащите поле Валюта_учета_количества_ГК в область Значения .

    На странице Выберите макет выберите параметры размещения отчета. Щелкните Далее .

    На странице Выберите стиль выберите стиль, чтобы указать способ форматирования отчета. Нажмите кнопку Готово .

    Структура отчета отображается в Report Builder. Сведения о создании или выполнении отчета см. в описании следующей процедуры.

    Завершив проектирование отчета, можно создать или выполнить отчет. Нажмите кнопку Выполнить на панели элементов Report Builder. Отчет будет выведен на экран.

    Использование Kerberos при работе с SQL Server Reporting Service

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

    По работе с Kerberos и делегированием написано достаточно, как на русском (http://www.osp.ru/winitpro/2011/03/13009255/), так и на английском языке, и пересказывать весь этот материал – пустая трата времени. В данной статье мы лишь обратимся к практической части настройки системы делегирования.

    Здесь я постарался изложить в доступной форме пошаговую инструкцию, которая позволит вам не только настроить Kerberos для работы с SQL Server Reporting Service (SSRS), но и с другим подобными сервисами, использующими SQL Server.

    Несколько слов о конфигурации.

    Мы имеем пять действующих лиц. Три из них это основные и две вспомогательные.

    К основным относятся:

    • Web-клиент, выполняющий запрос к порталу SSRS.
    • SQL Server Reporting Service (SSRS) базы которого размещены на SQL Server.
    • И собственно SQL Server.

    Немного об этой тройке.

    Если SSRS и SQL Server размещены на одном сервере, то проблем, о которых мы будем говорить ниже, не возникает, поскольку (в такой конфигурации) нет потребности в делегировании, и, в крайнем случае (при проблемах с Kerberos), сработает NTLM-аутентификация и запрос от SSRS к SQL Server будет выполнен.

    Основные трудности возникают при “выносе” SQL Server на отдельный компьютер. В чем суть возникающей проблемы? А суть состоит в том, что при таком размещении NTLM аутентификация не сработает, поскольку не она “не умеет” передавать данные о пользователе с SSRS на SQL Server. При такой конфигурации SSRS примет запрос от Web-клиента, в котором будут данные о пользователе, прошедшем аутентификацию либо по NTLM, либо по Kerberos, но без дополнительных настроек эти данные терминируются на SSRS и далее не передаются. В результате SSRS будет пытаться выполнять запрос к SQK Server используя анонимное подключение, которое по умолчанию запрещено, что приведет к ошибке выполнения запроса. В прошлые времена мы решали эту проблему просто создавая отдельную учетную запись от которой выполнялся запрос к SQL Server. Однако такое решение имеет серьезные риски безопасности, поскольку не позволяет разграничить доступ к данным на SQL Server в соответствии с полномочиями пользователей.

    Какое же решение мы можем использовать при размещении всех компонент на разных компьютерах?

    Мы должны использовать Kerberos аутентификацию и делегирование.

    Для реализации этого нам понадобятся еще две обязательные дополнительные компоненты:

    • Контроллер домена (DC).
    • Служба разрешения доменных имен (DNS).

    Контроллер домена будет выполнять несколько функций (http://www.osp.ru/winitpro/2011/03/13009255/), а DNS – выполнять разрешение имен в IP-адреса.

    И так приступим.


    Ниже приведена конфигурация, с которой мы будем работать.

    Подключимся к точке 3 и выполним запрос.

    Как видно из результат выполнения запроса SSRS использует для подключения к SQL Server NTLM аутентификацию.

    Откроем SQL Server Management Studio на SSRS и подключимся к SQL Server (точка 2).

    Как видно из результатов выполнения запроса, все подключения выполняются с аутентификацией NTLM.

    Выполним с SSRS (2) запрос, который мы будем использовать для отчета.

    И еще раз посмотрим на SQL Server (3), какой метод аутентификации использует запрос.

    Как и ожидалось это опять NTLM.

    Давайте попробуем открыть отчет, созданный с помощью Report Builder и использующий запрос, показанный выше.

    Все сработало. Неужели Report Builder использует протокол Kerberos вместо NTLM?

    Нет. Тоже NTLM. Так почему все работает?

    Давайте выполним тот же отчет с SSRS.

    С SSRS отчет не работает, выдавая какую-то странную ошибку о попытке анонимного логона.

    Посмотрим тип аутентификации.

    Как видно в обоих случаях (и с Report Builder и с SSRS) используется NTLM. Почему в одном случае отчет работает, а во втором нет?

    При работе с Report Builder пользователь передает ему свой маркер доступа (Token Assess, TA), полученный от контроллера домена, и приложение (а Report Builder это приложение), передает TA на SQL Server. Поскольку у меня есть логин на сервере баз данных и этот логин имеет достаточно привилегий, то все работает правильно и отчет выполняется.

    При работе же с SSRS пользователь обращается к Reporting Service, а уже он от своего имени пытается выполнить запрос. Он не может передать мой маркер доступа на SQL Server поскольку он не может произвести делегирование (передачу как эстафетной палочки) моей учетной записи на SQL Server. Для выполнения такой операции необходим Kerberos, этот злой трех-головый пес охраняющий вход.

    Почему же SQL Server не использует Kerberos аутентификацию?

    А все потому, что не выполнено одно из условий использования Kerberos – наличие Service Principal Name (SPN) для учетной записи от которой стартован SQL Server. Об SPN написано много статей (https://technet.microsoft.com/ru-ru/library/cc280745%28v=sql.105%29.aspx?f=255&MSPPError=-2147217396), и я их повторять не буду. Я просто возьму и создам SPN-ы для учетной записи от которой стартован SQL Service.

    Создать SPN-ы можно с использование специальной утилиты SETSPN.EXE (https://technet.microsoft.com/ru-ru/library/ms191153(v=sql.105).aspx), а для ленивых (к которым отношусь и я) можно воспользоваться графической оболочкой на контроллере домена. Однако, хотя графическая оболочка – это удобно, я вам все же рекомендую разобраться и с возможностями утилиты. У нее есть ключ, позволяющий проверять наличие дублированных SPN (ключ -X), а также ключ позволяющий, создавая SPN, сразу проверять на наличие дублированных и если они есть, то заменять их (ключ -D). По правде сказать, наличие дублированных SPN наиболее часто встречающаяся проблема почему не работает Kerberos.

    Создадим SPN-ы для SQL Server из графической оболочки оснастки Active Directory Users and Computers.

    Обратите внимание, что создано два SPN-а. Один с коротким именем, один с длинным. Принцип такой: вы ДОЛЖНЫ создавать SPN-ы таким образом, каким вы собираетесь обращаться к данному сервису.

    В данном случае вы сможете обратиться к SQL Service либо через SQL2020-N1 на порт 1433, либо через SQL2020-N1.demo.local на порт 1433.

    Выполним запрос к SQL Server из SSRS (2), используя SQL Server Management Studio (SSMS).

    Обратите внимание, что уже для подключения через SSMS используется Kerberos. Однако SSRS все еще использует протокол NTLM. Для решения этой проблемы выполним рестарт Reporting Service.

    После рестарта проверим режим аутентификации.

    Вот теперь все как нужно.

    Попробуем обратиться через SSRS.

    Результат один и тот же.

    Давайте выполним обращение с рабочей станции (1).

    Обратите внимание, что здесь уже другая ошибка. Это связано с тем какая информация передается на рабочую станцию.

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

    Давайте посмотрим что происходит на SQL Server, воспользовавшись утилитой KLIST.EXE для просмотра информации по Kerberos.

    Выполните на SQL Server команду KLIST.EXE sessions. Эта команда показывает сессии установленные к SQL Server. Попытайтесь отыскать строчку, где “x” это произвольные цифры.

    [x] Session 0 0:0xxxxxxxx DEMO\Test Kerberos:Network

    Вы не сможете найти такую строку поскольку не работает делегирование, и информация о пользователе DEMO\Test не попадает на SQL Server.

    Для решения данной проблемы выполним несколько действий:

    1. Установите SPN-ы (как показано на рисунке ниже) для пользователя от которого функционирует Reporting Service.
    1. Проверим, что в свойствах учетной записи, от которой стартован Reporting Service, не установлено свойство “Account is sensitive and cannot be delegated
    2. В свойствах компьютерного объекта, на котором функционирует Reporting Service, в закладке Delegationустновите “Trust this computer for delegation to any service (Kerberos only)
    3. В свойствах пользователя, от которого функционирует Reporting Service, в закладке Delegationустновите “Trust this user for delegation to any service (Kerberos only)
      Примечание: Если у пользователя нет такой закладки, то это значит, что не установлен ни один SPN.

    Теперь все условия выполнены, и попробуем еще раз выполнить обращение через Reporting Service к SQL Server.

    Проверим наличие Kerberos сессии на SQL Server

    KLIST.EXE sessions

    Просмотрим результат и видим, что появилась строка с сессией для пользователя DEMO\Test.

    Прежде чем завершить мое изложение, одно замечаение: Kerberos работает только с именами серверов, а IP-адреса он получает через DNS, поэтому создание SPN-а, содержащего IP-адрес, как показано ниже, не даст вам возможность использовать Kerberos при обращении по IP-адресу.

    До свидания коллеги, до следующих встреч.

    Александр Каленик, Senior Premier Field Engineer (PFE), MSFT (Russia)

    Получение уведомлений ms sql сервера в с builder

    1. Вступление. Настройка SQL для отправки писем.
    2. Модернизируем механизм отправки писем с помощью правил.
    3. Пишем Delphi клиента, для управления правилами.

    Часть 1. Введение.

    В некоторое время назад, мне нужен был механизм для отправки почтовых сообщений. Понятное дело, что это просто сделать используя Delphi, но мне надо использовать MS Navision и SQL сервер.

    Понятное дело, что в первую очередь я вспомнил, что SQL server умный и умеет отправлять почту. Но потом я вспомнил, что где то читал, что для этого нужно разворачивать Exchange Server, а это надо разбираться, опять же пинать админов… в общем довольно безнадежное дело, поэтому я тогда пошел в обход. Я создал табличку SendMail и стал писать туда письма для отправки, а потом написал delphi клиента, который Job-ом дергался каждые 5 мин и отправлял письма из этой таблички.

    Система оказалась вполне рабочей. Но вот сегодня наконец-то решил разобраться с настройками SQL server-а для отправки писем.

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

    Рассмотрим как же настроить отправку писем. Это оказалось довольно просто.

    В SQL 2005 отправку можно реализовать 2мя способами —

    1) служба SQL Mail, из SQL Server 2000. Требует Exchange Server или клиента Outlook-а. SQL Mail не рекомендуют использовать, т.к. её поддержки больше не будет в дальнейших версиях. Этот способ мы рассматривать не будем.

    2) Database Mail – новый компонент SQL 2005, он позволяет отправлять почту используя smtp протокол на прямую. Его то мы и рассмотрим.

    Подробно почитать о том, чем хорош этот компонент и как он устроен, можно тут.

    Итак, открываем Database Mail:

    По умолчанию этот компонент не активен, при первом запуске, SQL предложит его активировать.
    Далее:

    Нажимаем Далее, задаём имя профиля, ниже нажимаем ADD SMTP account, в появившемся окошке, указываем настройки почтового ящика, с которого пойдет рассылка писем.Можно указать несколько ящиков, тогда, как я понял, при недоступности первого, отправка пойдет на следующий.

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

    Далее настраиваем параметры почты,

    тут наиболее интересные – максимальный размер аттача, список запрещенных расширений для аттачей, уровень логов (если стоит Advanced – по умолчанию, то копии всех писем сохраняются в базе msdb, нам там этот хлам ни к чему, поставим Normal).

    Всё тоже самое можно сделать и программно.

    Собственно, на этом настройка почты завершена, далее надо назначить роль DatabaseMailUserRole для базы msdb пользователям, которым разрешенно отправлять почту. Далее можно использовать для отправки почты процедуру – sp_send_dbmail.

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

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

    Для этого нам нужен будет запущенный SQL Server Agent (собственно без него и не будет работать вышеназванные механизмы). В моем случае агент работает под ролью sysdba, если это не так, то надо настроить учетке, под которой он работает, роль DatabaseMailUserRole.

    Далее, идем в св-ва Agent-а и настраиваем ему разрешение на использование email и почтовый профиль.

    Что бы изменения вступили в силу, надо перезапустить агента.

    Далее создаём получателей наших уведомлений:

    Я создал 2х получателей – программистов (они будут получать сообщения о проблемах выполнения Job-ов и репликации) и сис админов (они будут получать уведомления о Job-ах, которые делают бэкап и обычно падают из-за нехватки места). Описывать создание не буду, там всё ясно – имя и список адресов через «;». Вообще то, MS говорит что указывать надо адрес почтовых синонимов, с которого пойдет переадресация на конкретных получателей. Но длина поля позволяет забить несколько адресов.

    А теперь идем в свойства Job-ов и указываем кого уведомить при возникновении ошибки:

    Ну всё, теперь можите спать спокойно, если упадет ваша хп, то вы узнаете об этом…

    Что бы настроить уведомления репликации, надо запустить Replication Monitor и правой кнопкой по названию публикации, там будет настройка уведомлений.

    О том как отправлять письма из обычных хп и внешних систем, мы поговорим в продолжении…

    Это кросспост из блога «Блог жителей Чертенка.ру»
    Вы можете посмотреть коментарии и оставить свои комертарии тут
    (регистрация не нужна)

    Как подключиться к базе данных SQL Server с помощью C++ Builder


    Как я могу подключиться к базе данных SQL Server с помощью C++ Builder?

    Когда я удаляю компонент SQLConnection, я не могу найти место, чтобы удалить строку подключения в. И как я могу ввести строку соединения в C++ Builder? Это то же самое, что и в С#?

    Используйте компоненты ADO. Вы можете использовать компонент TADOConnection, где вы можете ввести строку подключения, а затем добавить TADOTable для каждой таблицы базы данных или TADOQuery для SQL-запросов. И TADOTable, и TADOQuery имеют свойство Connection, в котором вы выберете свой компонент TADOConnection.

    Если у вас есть компонент TADOConnection в форме VCL или форме базы данных, вы можете щелкнуть ссылку в окне свойств, чтобы изменить ConnectionString. В противном случае вы можете щелкнуть правой кнопкой мыши по объекту в форме и щелкнуть там Edit ConnectionString. Откроется диалоговое окно ConnectionString, в котором можно либо подключиться к файлу данных, либо использовать строку подключения. Вы хотите использовать строку подключения. Там вы можете вставить свою старую строку подключения и посмотреть, работает ли она, или использовать кнопку Build. справа, чтобы выбрать поставщика, такого как собственный клиент SQL Server 11.0, а затем нажать Далее >>. Затем на вкладке «Соединение» выберите все параметры соединения и нажмите кнопку «Проверить соединение», чтобы проверить его. Это гораздо лучше, чем пытаться отладить соединение в вашем приложении. Как только он заработает, сохраните его, нажав кнопку ОК.

    Расширение возможностей баз данных Microsoft SQL Server c помощью функций определяемых пользователем. Часть 1. Создание SQLCLR сборки

    Язык Transact-SQL (T-SQL) Microsoft SQL Server (MS SQL) обладает довольно широкими возможностями не только в плане построения запросов, но и разработки серверной бизнес логики (back-end). Но, тем не менее, эти возможности далеко не безграничны.

    Существует 2 основных подхода к решению задач не подвластных T-SQL.

    • Реализация необходимого функционала в рамках клиентского приложения либо сервера приложения (при трёхзвенной архитектуре);
    • Использование внутри базы данных (БД) программного кода .NET. Конкретно, технологии SQLCLR.

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

    С помощью технологии SQLCLR можно «научить» БД выполнять сложные алгоритмы по обработке данных. Если учесть, то, что в SQLCLR доступен практически весь арсенал средств .NET (за исключением разве что визуального интерфейса), то, в случае необходимости, можно разработать БД, которая полностью реализует всю бизнес-логику. Клиентской программе остаётся только запрашивать и отображать полученные данные либо отправлять в БД новые для обработки.

    Для того чтобы проиллюстрировать использование технологии SQLCLR воспользуемся простым, но, в тоже время, весьма показательным примером. Реализуем вычисление МD5 для строки непосредственно в БД. Эту задачу нельзя решить штатными средствами T-SQL, но с помощью SQLCLR это становится возможным.

    Вначале создадим в Visual Studio, так называемый, «Проект базы данных SQL Server».

    Создадим функцию, которая будет вычислять MD5 для строки.

    Использование Kerberos при работе с SQL Server Reporting Service

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

    По работе с Kerberos и делегированием написано достаточно, как на русском (http://www.osp.ru/winitpro/2011/03/13009255/), так и на английском языке, и пересказывать весь этот материал – пустая трата времени. В данной статье мы лишь обратимся к практической части настройки системы делегирования.

    Здесь я постарался изложить в доступной форме пошаговую инструкцию, которая позволит вам не только настроить Kerberos для работы с SQL Server Reporting Service (SSRS), но и с другим подобными сервисами, использующими SQL Server.

    Несколько слов о конфигурации.

    Мы имеем пять действующих лиц. Три из них это основные и две вспомогательные.

    К основным относятся:

    • Web-клиент, выполняющий запрос к порталу SSRS.
    • SQL Server Reporting Service (SSRS) базы которого размещены на SQL Server.
    • И собственно SQL Server.

    Немного об этой тройке.

    Если SSRS и SQL Server размещены на одном сервере, то проблем, о которых мы будем говорить ниже, не возникает, поскольку (в такой конфигурации) нет потребности в делегировании, и, в крайнем случае (при проблемах с Kerberos), сработает NTLM-аутентификация и запрос от SSRS к SQL Server будет выполнен.

    Основные трудности возникают при “выносе” SQL Server на отдельный компьютер. В чем суть возникающей проблемы? А суть состоит в том, что при таком размещении NTLM аутентификация не сработает, поскольку не она “не умеет” передавать данные о пользователе с SSRS на SQL Server. При такой конфигурации SSRS примет запрос от Web-клиента, в котором будут данные о пользователе, прошедшем аутентификацию либо по NTLM, либо по Kerberos, но без дополнительных настроек эти данные терминируются на SSRS и далее не передаются. В результате SSRS будет пытаться выполнять запрос к SQK Server используя анонимное подключение, которое по умолчанию запрещено, что приведет к ошибке выполнения запроса. В прошлые времена мы решали эту проблему просто создавая отдельную учетную запись от которой выполнялся запрос к SQL Server. Однако такое решение имеет серьезные риски безопасности, поскольку не позволяет разграничить доступ к данным на SQL Server в соответствии с полномочиями пользователей.

    Какое же решение мы можем использовать при размещении всех компонент на разных компьютерах?

    Мы должны использовать Kerberos аутентификацию и делегирование.

    Для реализации этого нам понадобятся еще две обязательные дополнительные компоненты:

    • Контроллер домена (DC).
    • Служба разрешения доменных имен (DNS).

    Контроллер домена будет выполнять несколько функций (http://www.osp.ru/winitpro/2011/03/13009255/), а DNS – выполнять разрешение имен в IP-адреса.

    И так приступим.

    Ниже приведена конфигурация, с которой мы будем работать.

    Подключимся к точке 3 и выполним запрос.

    Как видно из результат выполнения запроса SSRS использует для подключения к SQL Server NTLM аутентификацию.

    Откроем SQL Server Management Studio на SSRS и подключимся к SQL Server (точка 2).

    Как видно из результатов выполнения запроса, все подключения выполняются с аутентификацией NTLM.

    Выполним с SSRS (2) запрос, который мы будем использовать для отчета.

    И еще раз посмотрим на SQL Server (3), какой метод аутентификации использует запрос.

    Как и ожидалось это опять NTLM.

    Давайте попробуем открыть отчет, созданный с помощью Report Builder и использующий запрос, показанный выше.

    Все сработало. Неужели Report Builder использует протокол Kerberos вместо NTLM?

    Нет. Тоже NTLM. Так почему все работает?

    Давайте выполним тот же отчет с SSRS.

    С SSRS отчет не работает, выдавая какую-то странную ошибку о попытке анонимного логона.

    Посмотрим тип аутентификации.

    Как видно в обоих случаях (и с Report Builder и с SSRS) используется NTLM. Почему в одном случае отчет работает, а во втором нет?

    При работе с Report Builder пользователь передает ему свой маркер доступа (Token Assess, TA), полученный от контроллера домена, и приложение (а Report Builder это приложение), передает TA на SQL Server. Поскольку у меня есть логин на сервере баз данных и этот логин имеет достаточно привилегий, то все работает правильно и отчет выполняется.

    При работе же с SSRS пользователь обращается к Reporting Service, а уже он от своего имени пытается выполнить запрос. Он не может передать мой маркер доступа на SQL Server поскольку он не может произвести делегирование (передачу как эстафетной палочки) моей учетной записи на SQL Server. Для выполнения такой операции необходим Kerberos, этот злой трех-головый пес охраняющий вход.

    Почему же SQL Server не использует Kerberos аутентификацию?

    А все потому, что не выполнено одно из условий использования Kerberos – наличие Service Principal Name (SPN) для учетной записи от которой стартован SQL Server. Об SPN написано много статей (https://technet.microsoft.com/ru-ru/library/cc280745%28v=sql.105%29.aspx?f=255&MSPPError=-2147217396), и я их повторять не буду. Я просто возьму и создам SPN-ы для учетной записи от которой стартован SQL Service.

    Создать SPN-ы можно с использование специальной утилиты SETSPN.EXE (https://technet.microsoft.com/ru-ru/library/ms191153(v=sql.105).aspx), а для ленивых (к которым отношусь и я) можно воспользоваться графической оболочкой на контроллере домена. Однако, хотя графическая оболочка – это удобно, я вам все же рекомендую разобраться и с возможностями утилиты. У нее есть ключ, позволяющий проверять наличие дублированных SPN (ключ -X), а также ключ позволяющий, создавая SPN, сразу проверять на наличие дублированных и если они есть, то заменять их (ключ -D). По правде сказать, наличие дублированных SPN наиболее часто встречающаяся проблема почему не работает Kerberos.

    Создадим SPN-ы для SQL Server из графической оболочки оснастки Active Directory Users and Computers.

    Обратите внимание, что создано два SPN-а. Один с коротким именем, один с длинным. Принцип такой: вы ДОЛЖНЫ создавать SPN-ы таким образом, каким вы собираетесь обращаться к данному сервису.

    В данном случае вы сможете обратиться к SQL Service либо через SQL2020-N1 на порт 1433, либо через SQL2020-N1.demo.local на порт 1433.

    Выполним запрос к SQL Server из SSRS (2), используя SQL Server Management Studio (SSMS).

    Обратите внимание, что уже для подключения через SSMS используется Kerberos. Однако SSRS все еще использует протокол NTLM. Для решения этой проблемы выполним рестарт Reporting Service.

    После рестарта проверим режим аутентификации.

    Вот теперь все как нужно.

    Попробуем обратиться через SSRS.

    Результат один и тот же.

    Давайте выполним обращение с рабочей станции (1).

    Обратите внимание, что здесь уже другая ошибка. Это связано с тем какая информация передается на рабочую станцию.

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

    Давайте посмотрим что происходит на SQL Server, воспользовавшись утилитой KLIST.EXE для просмотра информации по Kerberos.

    Выполните на SQL Server команду KLIST.EXE sessions. Эта команда показывает сессии установленные к SQL Server. Попытайтесь отыскать строчку, где “x” это произвольные цифры.

    [x] Session 0 0:0xxxxxxxx DEMO\Test Kerberos:Network

    Вы не сможете найти такую строку поскольку не работает делегирование, и информация о пользователе DEMO\Test не попадает на SQL Server.

    Для решения данной проблемы выполним несколько действий:

    1. Установите SPN-ы (как показано на рисунке ниже) для пользователя от которого функционирует Reporting Service.
    1. Проверим, что в свойствах учетной записи, от которой стартован Reporting Service, не установлено свойство “Account is sensitive and cannot be delegated
    2. В свойствах компьютерного объекта, на котором функционирует Reporting Service, в закладке Delegationустновите “Trust this computer for delegation to any service (Kerberos only)
    3. В свойствах пользователя, от которого функционирует Reporting Service, в закладке Delegationустновите “Trust this user for delegation to any service (Kerberos only)
      Примечание: Если у пользователя нет такой закладки, то это значит, что не установлен ни один SPN.

    Теперь все условия выполнены, и попробуем еще раз выполнить обращение через Reporting Service к SQL Server.

    Проверим наличие Kerberos сессии на SQL Server

    KLIST.EXE sessions

    Просмотрим результат и видим, что появилась строка с сессией для пользователя DEMO\Test.

    Прежде чем завершить мое изложение, одно замечаение: Kerberos работает только с именами серверов, а IP-адреса он получает через DNS, поэтому создание SPN-а, содержащего IP-адрес, как показано ниже, не даст вам возможность использовать Kerberos при обращении по IP-адресу.

    До свидания коллеги, до следующих встреч.

    Александр Каленик, Senior Premier Field Engineer (PFE), MSFT (Russia)

    Илон Маск рекомендует:  Foxpro начинает взаимодействовать с браузерами www
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL
    Примечание