Сервис событий в SQL-сервере


Оглавление (нажмите, чтобы открыть):

Разработка и публикация отчета в SQL Server Reporting Services (SSRS)

Итак, давайте приступим к рассмотрению процесса разработки и публикации отчетов в SQL Server Reporting Services, и в качестве примера мы будем использовать SSRS 2008 R2, а разработку отчета будем производить в среде SQL Server Business Intelligence Development Studio, также 2008 версии.

Напомню, что в предыдущих материалах мы с Вами рассматривали возможности и основные компоненты SSRS, а также установку и настройку служб Reporting Services, а сегодня мы переходим к разработке отчетов, поэтому предполагается, что у Вас уже развернут и настроен SQL Server Reporting Services.

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

Исходные данные для создания отчета

Как я уже сказал, в качестве конструктора мы будем использовать среду SQL Server Business Intelligence Development Studio, а в качестве источника данных у нас будет выступать тестовая таблица в тестовой базе данных расположенной на SQL Server 2008 R2.

Таблица у нас будет следующая (описание полей чуть ниже):

    >Другими словами, наша таблица содержит список товаров, их цену и города, в которых они были произведены.

Кстати, если кому интересна тема SQL Server и Transact-SQL, то рекомендую почитать следующие материалы:

Сами данные у нас будут, допустим, следующие

И на основе этих данных мы будем строить отчет.

Разработка отчета в Business Intelligence Development Studio

Переходим к разработке отчета, открываем Business Intelligence Development Studio (BIDS) «Пуск ->Все программы-> Microsoft SQL Server 2008 R2-> Среда SQL Server Business Intelligence Development Studio».

Создание проекта сервера отчетов

Далее нам необходимо вызвать окно создания проекта, это мы можем сделать на начальной странице, используя кнопку «Создать проект» или через меню «Файл ->Создать -> Проект».

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

Затем давайте сразу зададим адрес сервера отчетов для нашего проекта, сам адрес можно посмотреть в диспетчере конфигурации служб Reporting Services в пункте «URL-адрес веб-службы», по умолчанию на локальном компьютере это — https://localhost/ReportServer.

В BIDS выбираем меню «Проект -> Свойства (конфигурация Release)» и в пункте TargetServerURL указываем наш адрес.

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

Теперь мы можем сразу из BIDS опубликовывать отчеты на сервере отчетов.

Создание общего источника данных

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

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

Затем указываем название нашего источника и, соответственно, выбираем, что это за источник. В нашем примере это «Microsoft SQL Server».

Для указания строки подключения нажимаем Правка, и заполняем соответствующие данные, т.е. в нашем случае это localhost, база данных test. Также здесь необходимо задать тип проверки подлинности, если указать тип «Использовать проверку подлинности Windows», то вход на SQL сервер будет выполнен от имени учетной записи, под которой Вы загрузили операционную систему. Если указать «Использовать проверку подлинности SQL Server», то, соответственно, на сервере должна быть заведена специальная учетная запись и, конечно же, сам сервер должен быть настроен на такой способ проверки подлинности. Для примера я буду использовать проверку подлинности Windows.

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

Создание отчета

Теперь давайте создадим сам отчет, для этого в обозревателе решений щелкаем правой кнопкой по пункту «Отчеты ->Добавить ->Создать элемент»

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

Затем в окне «Добавление нового элемента» в шаблонах мы выбираем «Отчет» и в пункте имя задаем имя нашего отчета.

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

Например, мне удобно вот так

Теперь создаем источник данных для отчета, т.е. как договорились, создаем ссылку на общий источник данных. Для этого в окне «Данные отчета» жмем «Создать ->Источник данных» или также можно щелкнуть правой кнопкой по пункту источники данных.

Где мы задаем имя источника данных и выбираем пункт «Использовать ссылку на общий источник данных», жмем «ОК».

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

Жмем «Создать ->Набор данных» или снова через правую кнопку.

В окне «Свойства набора данных» мы задаем имя набора данных, выбираем пункт «Использовать набор данных, внедренный в отчет» и в текст запроса соответственно вставляем наш запрос, жмем «ОК»

Нам осталось спроектировать сам шаблон вывода информации, для этого на макет с «Панели элементов» перетащите элемент «Таблица». Этот элемент отлично подходит для отображения табличных данных.

Теперь можно перетащить поля с набора данных в эту таблицу, для отображения.

В принципе можно сразу проверить работу данного отчета, для этого перейдите на вкладку «Просмотр», т.е. таким образом можно производить отладку без опубликования отчета на сервере.

А для опубликования отчета и всего проекта на сервере отчетов, необходимо в пункте меню «Построение» нажать «Развернуть Тестовый проект»

После чего, если Вы зайдете в «Диспетчер отчетов», по умолчанию это https://localhost/Reports, то Вы увидите, что у Вас там появился каталог «Тестовый проект», в котором лежит отчет «Тест», а также появился соответствующий источник данных. Для запуска отчета перейдите в каталог и нажмите на отчет.

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

Надежное обслуживание баз MS SQL Server для занятых. Сервис событий в SQL-сервере

Ниже будет рассказано, как создать план обслуживания в с помощью программы «Среда SQL Sever Management Studio». В данной статье я просто постараюсь наглядно описать алгоритм создания плана обслуживания с помощью Мастера планов обслуживания, не вдаваясь в теоретическую часть вопроса. Получить больше информации по данной области можно изучив электронную документацию по SQL Server на сайте MSDN .

В описанный ниже план будут входить всего 2 задачи.

  • Резервное копирование базы данных.
  • Проверка целостности базы данных.

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

1. Исходные данные

  1. Операционная система семейства Windows (в моем примере используется )
  2. Установленный Microsoft SQL Server 2008 R2 (об установке SQL Server можно прочитать )
  3. Существующая база данный в SQL Server (о создании баз данных в SQL Server читайте )
  4. Настроенная компонента Database Mail, в случае если требуется уведомлять по электронной почте операторов о результатах выполнения плана обслуживания (о том как настроить компоненту Database Mail и создать оператора системы я писал ).

2. Проверка работы Агента SQL Server

Первое что нам необходимо сделать, это убедиться что Агент SQL Server установлен и работает. Для этого запустим оснастку «Службы » («Пуск » (Start ) — «Администрирование » (Administrative Tools ) — «Службы » (Services )) и в списке служб найдем службу «Агент SQL сервер » (SQL Server Agent ).

Откроем свойства этой службы (кликнув по ней 2 раза) и убедимся что:

  • Тип запуска стоит «Автоматически » (Startup type: Automatic);
  • Состояние «Работает » (Service status: Started);

В противном случае, необходимо изменить параметры как на скриншоте выше и сохранить настройки нажав «Применить » (Apply) .

Теперь запустим программу «Среда SQL Sever Management Studio» («Пуск » (Start ) — «Все программы » (All programs) — «Microsoft SQL Server 2008 R2 » — «Средства SQL Server 2008 R2 «) и введем данные для авторизации.

После чего, еще раз убедимся что Агент SQL Server работает (в обозревателе объектов должна быть вкладка «Агент SQL Server » (SQL Server Agent) с зеленой иконкой слева.

3. Создание плана обслуживания

Теперь перейдем непосредственно к созданию плана обслуживания. В обозревателе объектов (Object Explorer) раскроем вкладку «Управление » (Management), кликнем правой кнопкой мыши по вкладке «Планы обслуживания » (Maintenance Plans) и в контекстном меню выберем «Мастер планов обслуживания » (Maintenance Plan Wizard) .

В запустившемся мастере планов обслуживания на странице приветствия нажимаем «Далее » (Next) и в следующем окне вводим имя и описание нового плана.

Затем необходимо определиться с расписанием, по которому будет выполняться данный план обслуживания. Для этого установим переключатель на «Единое расписание для всего плана или без расписания » (Single schedule for the entire plan ore no schedule ) и нажмем «Изменить… » (Change…) для назначения расписания.

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

  • Выполняется — «Еженедельно » (Occurs — Weekly);
  • Повторяется каждые — «1 нед. » в «Воскресенье » (Recurs every: 1 week(s) on Sunday);
  • Выполняться один раз в день в: — «2:00:00» (Occurs onсe at: «2:00:00»);


Еще раз убедимся, что расписание задано верно, и нажмем «Далее » (Next) .

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

  1. Проверка целостности базы данных (Check Database Integrity);
  2. Резервное копирование базы данных (полное) (The Back Up Database (Full));

Заметьте, что для каждой задачи приводится ее краткое описание в поле снизу. Выбрав необходимые задачи, жмем «Далее » (Next) .

Теперь необходимо задать порядок выполнения задач, используя кнопки «Вверх… » (Move Up) и «Вниз… » (Move Down). Установив порядок, жмем «Далее » (Next) .

Здесь требуется задать параметры для каждой задачи в плане. Первая задача в нашем списке это «Копирование БД (полное) » (Back Up Database (Full)).

Прежде всего необходимо выбрать базы данных для резервного копирования, нажав на кнопку выбора списка «Определенные базы данных » (Select one ore more). Выбрав необходимые для резервного копирования базы данных, нажимаем «ОК » .

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

  1. Если установить переключатель «Создать файл резервной копии для каждой базы данных » (Create a backup file for every database) , то при выполнении задания в выбранной директории будет создаваться несколько файлов резервных копий с именами, соответствующими названиям баз данных. Ну а установка флага «Создавать вложенный каталог для каждой базы данных » (Create a sub-directory for each database) разложит файлы по отдельным папкам. Обратите внимание, что необходимо оставить заполненным расширение файла резервной копии.
  2. Установка флага «Срок действия резервного набора данных истекает » (Backup set will expire) указывает SQL-серверу, когда этот набор может быть перезаписан без явного пропуска проверки на истечение срока.
  3. Для наибольшей надежности, можно установить флаг «Проверять целостность резервной копии » (Verify backup integrity).
  4. Также рекомендую выбрать режим «Сжимать резервные копии » (Compress backup) для экономии дискового пространства, если используемая версия SQL Server поддерживает данную функцию.

Если дисковое пространство ограничено, можно также выбрать один файл для хранения резервной копии, который будет перезаписываться после каждого выполнения плана обслуживания. Для этого установим соответствующий переключатель на «Создать резервную копию баз данных в одном или нескольких файлах » (Back up databases across one ore more files) и указжем соответствующее имя файла (будьте внимательны, файл резервной копии следует задавать с расширением.bak), а также выберем режим «Перезаписать » в случае, если файлы резервной копии существуют (If backup files exist: Overwrite).

Теперь очередь задачи «Проверка целостности базы данных » (Database Check Integrity). Для нее всего лишь необходимо выбрать базу данных. В моем примере это все та же база данных, что и на предыдущем шаге. Определившись с базами, жмем «Далее » (Next).

На следующей странице возможно выбрать директорию, куда будет сохраняться лог выполнения задания, а также указать SQL Server для отправки отчета по электронной почте. Задав параметры, снова жмем «Далее » (Next).

Проверим еще раз все настройки плана обслуживания, и если все верно, нажимаем «Готово » (Finish).

Мастер начнет построение плана обслуживания. Если мастер не обнаружит ошибок, то увидим сообщение об успешном построении плана. В противном случае необходимо устранить ошибки и повторить процедуру снова. Закроем окно, нажав «Закрыть » (Close).

4. Запуск выполнения плана обслуживания

Для запуска выполнения плана обслуживания перейдем в программу «Среда Microsoft SQL Server Management Studio». Здесь, раскрыв вкладку «Планы обслуживания » (Maintenance Plans) увидим наш только что созданный план. Чтобы проверить его работу, кликнем по нему правой кнопкой мыши, и в контекстном меню выберем пункт «Выполнить » (Execute) .

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

А в соответствующих директориях должны появиться файл резервной копии

и файл лога выполнения плана.

Открыв, этот файл, вы должны увидеть примерно следующее:

Если все так, поздравляю! План обслуживания SQL Server создан и работает.

Помогла ли Вам данная статья?

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

  • Сервер 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 версии при переиндексации происходит отключение клиентов от базы данных на время работы данного шага.

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

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

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

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

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

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

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

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

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

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

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

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

    Я никогда не слышал, чтобы кто-нибудь в детстве мечтал стать администратором базы данных, когда вырастет. Жизнь просто приводит нас к этой профессии, хотя многим она очень даже нравится. Погружение в администрирование 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, но подробнее об этом я расскажу в другой статье.

    Мастер Йода рекомендует:  Ссылка с якорем в HTML

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

    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 и знать открывающиеся благодаря ему возможности настройки.

    Итак в продолжении темы обслуживания баз 1С присмотримся к системе управления реляционными базами данных Microsoft SQL Server. Этот продукт предоставляет нам большие возможности обработки, хранения, резервирования и восстановления баз. Я начну небольшой цикл статей, посвященных этой теме. Все, что будет написано ниже, является личным мнением по данному вопросу и подлежит критике.

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

    В тестовой лаборатории у нас следующее:

    • Сервер Windows Server 2008 Enterprise: SRV-1C-TEST .
    • Microsoft SQL Server 2008: SRV-1C-TEST .
    • Тестовая база BuhFirma .

    Как обычно, поставим перед собой задачу:

    Проводить обслуживание базы в период 00:30 — 01:00, при этом обслуживание не должно быть заметным (либо слабозаметным) для пользователей базы.

    Начнём с важных моментов. MS SQL база данных может иметь один из трех типов модели восстановления:

    • Простая.
    • Полная.
    • С неполным протоколированием.

    Так же при резервном копировании нам предоставляется на выбор три варианта копирования:

    • Полное.
    • Разностное.
    • Копирование журнала транзакций (логов).

    При полном варианте копирования происходит сохранение базы mdf и журнала транзакций. Разностное копирование (по-другому дифференциальное) производит копирование данных, изменившихся с момента создания последней полной резервной копии. Копирование журнала транзакций соответственно производит сохранение только самого журнала транзакций.

    При выборе простой модели восстановить базу данных можно с момента создания последней разностной или полной резервной копии. При выборе полной модели восстановления мы можем восстанавливать базу до минуты, создав полную резервную копию, например, ночью, и в течение дня создавать копии журнала транзакции. Ниже мы увидим, где всплывает этот момент. Хотелось так же привести некоторые выдержки из MSDN : «Модель восстановления с неполным протоколированием предназначена исключительно как дополнение к модели полного восстановления. В общем случае модель восстановления с неполным протоколированием похожа на модель полного восстановления, за исключением того, что протоколирование большинства массовых операций в ней производится в минимальной степени».

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

    В MSSQL 2008 по умолчанию в созданных базах данных модель восстановления Полная .

    Как выбрать модель восстановления? Надо лишь ответить на вопрос: смертельна ли потеря информации за время, прошедшее после полного резервного копирования? Если ответ да, тогда выбираем полную модель восстановления, если нет, простую. Модель с неполным протоколированием стоит применять только на время массовых операций в БД.

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

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

    • Проверка целостности базы
    • Перестроение индекса
    • Обновление статистики
    • Очистка процедурного кэша СУБД
    • Резервное копирование базы данных
    • Очистка после обслуживания
    • Очистка журнала

    Для этого подключимся к MSSQL серверу с помощью среды Microsoft SQLServer Management Studio . Запустить среду можно перейдя в Пуск — Все программы — Microsoft SQL Server 2008 .

    Подключимся с серверу SQL и перейдем в Управление — Планы Обслуживания . Кликнем правой кнопкой по Планы обслуживания и выберем Создать план обслуживания . Дадим ему имя: SRV1CTEST .

    Перед нами окно SRV1CTEST, в котором мы и будем создавать последовательность действий, обозначенных раннее. Сразу видим появившейся Вложенный_План1 . Справа от названия вложенного плана вы увидите иконку в виде таблички. Нажимаем на нее и попадаем в свойства расписания задания. Здесь можно менять название вложенного плана, выставить частоту повторения в Ежедневно и установить время. И так теперь осталось наполнить наш план заданиями. Для этого с Панели инструментов, которая находится справой стороны, перетаскиваем задания.

    Начнем с Проверки целостности базы данных .

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

    Процедура Перестроение индекса пересоздает индекс с новым коэффициентом заполнения. За счет этого мы увеличиваем производительность работы в БД.

    Задача Обновление статистики обновляет сведения о данных таблиц для MS SQL. Что тоже повышает производительность. Но после этой операции надо обязательно проводить очистку кэша.

    Пока остановимся и поговорим о настройке связей между заданиями. Связи отражают последовательность выполнения. Что бы провести связь между заданиями надо нажать один раз на задание и увидите появившуюся стрелку. Её надо перетащить на следующее задание. У связи может быть 3 цвета: синий, зеленый и красный, каждый из которых означает три типа срабатывания перехода: при простом завершении предыдущего задания — Завершение , в случае успешного завершения — Успех , а в случае возникновения ошибки при выполнение предыдущего задания — Ошибка . Все эти параметры вы можете увидеть, нажав правой кнопкой мыши на проведенную между заданиями стрелку. Таким образом, если нам надо, чтобы Перестроение индекса срабатывало только после успешного завершения задания Проверка целостности базы данных , мы должны связать их стрелкой. Нажав правой кнопкой мыши на стрелку, сменим ее режим на Успешно , как видим, ее цвет изменился на зеленый.

    На данный момент мы имеем 3 созданных задания в нашем вложенном плане. Как вы могли заметить, задания Очистка процедурного кэша СУБД в панели элементов нету. Мы воспользуемся задачей Выполнение инструкции T-SQL . Перетащим ее в план, и щелкнем на ней два раза. Мы видим окно, в которое впишем следующее:

    Как отслеживать изменения в DB MS SQL 2008 на C# через Service Broker?

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

    • Приложение, написанное на C#
    • SQL Server, с базой данной на 3 таблички

    В программе делаю следующее:

    Кусок для SqlDependency писал по этому примеру

    В самой бд сделал ALTER DATABASE [Database_name] SET ENABLE_BROKER;

    Но. по какой-то причине, по ПКМ->Свойства->Отслеживание изменений в поле Отслеживание изменений висело False. Ну, ручками переключил на True.

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

    У меня появилось ряд вопросов, в ходе изучения матчасти.

    1) Queue. Как узнать имя моей очереди по дефолту. Как её конфигурировать? Потому что, как я понял, у меня не совсем полный код для SqlDependency, т.к. требуется

    но queueName я не знаю.

    2) Мне нужно только узнавать о том, были изменения или нет. Какие конкретно, мне не важно, и непонятно для чего в примере висит этот кусок:

    Точнее как, понятно, что по идее по правильному я должен подтянуть те самые изменения из Queue и уже дальше работать с ними, к примеру, ими заполнить ячейку в гриде, а не заполнять заново весь грид (но он у меня мелкий и особо я не теряю от Fill), но, вероятно, это что-то нужное, раз у меня не влзелето?

    3) Как в SQL SMS проверить работает ли вообще Service Broker? Я читал про сообщения в бд, на которые должен, якобы, ответить Service Broker, но конкретного ничего не вычитал (что он должен ответить, в какой форме, куда, как смотреть этот пакет в таком случае).


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

    Работа с журналом событий SQL Server

    В процессе функционирования SQL Server ведет журнал, в котором регистрирует события, связанные с работой сервера. В документации этот журнал называется Error Log, что не вполне соответствует действительности. Правильнее было бы именовать его Event Log, так как в нем отмечается множество событий различного характера из разных источников, включая системные информационные и системные аварийные события, сообщения аудита регистрации и пользовательские сообщения (если сравнивать с операционной системой, то в Windows NT/2000 события регистрируются в трех журналах — Application, Security и System).

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

    Что такое Error Log

    При каждом запуске SQL Server начинает новый журнал Error Log, который представляет собой текстовый файл, расположенный по умолчанию в каталоге MSSQLLog. Файлы журналов, созданные при предыдущих запусках, не удаляются, а просто переименовываются. Текущий файл журнала имеет имя Error Log, файл предыдущего запуска Error Log.1 и т. д. По умолчанию SQL Server хранит файлы шести предыдущих журналов. Проще всего просмотреть журналы в Enterprise Manager (см. Рисунок 1 ). Изменить местоположение файлов журнала можно, используя параметр -e при старте сервера. В Enterprise Manager это делается через контекстное меню SQL Server properties: закладка General — Startup Parameters (см. Рисунок 2).

    Рисунок 2. Установка параметров запуска SQL Server.

    Число сохраняемых журналов устанавливается в Enterprise Manager c помощью контекстного меню SQL Server Logs Configure (см. Рисунок 3). Можно сохранять не более 99 журналов предыдущих запусков.

    Рисунок 3. Установка параметров Error Log.

    При запуске SQL Server в журнал заносится следующая информация:

    • дата и время запуска;
    • используемые версии SQL Server и Windows NT/2000 с учетом Service Pack;
    • системный приоритет SQL Server и число процессоров в системе;
    • информация о подключении системных и пользовательских баз данных;
    • используемые сетевые библиотеки;
    • сведения о готовности SQL Server к работе с клиентскими соединениями.

    Если при запуске SQL Server возникли проблемы, можно с помощью любого текстового редактора прочитать файл Error Log и, возможно, обнаружить причину неудачи. При завершении работы сервер записывает в журнал причину этого события — либо была остановлена служба MSSQLSERVER (Server shut down by request), либо прекращена работа операционной системы (SQL Server terminating because of system shutdown). Если таких сообщений нет (естественно, не в текущем журнале), это означает, что работа компьютера не была завершена должным образом, например по причине аппаратного сбоя. Есть еще одно сообщение, которое может быть последним в Error Log, — в случае если был принудительно открыт новый файл журнала (Attempting to cycle errorlog). Об этом мы поговорим позже.

    Необходимо отметить, что по умолчанию все сообщения Error Log дублируются в журнале Windows Application Log. Двойную регистрацию событий можно отменить, запустив SQL Server с параметром -n. При этом нужно обязательно указать параметр -e, иначе события не будут записываться и в журнал Error Log.

    Какие события отражаются в Error Log

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

    К ним относятся:

    • копирование/восстановление базы данных;
    • нехватка дискового пространства в базе данных;
    • выполнение команды KILL.

    Можно организовать аудит удачных и неудачных попыток регистрации пользователей. В Enterprise Manager это делается с помощью контекстного меню SQL Server Properties: закладка Security — Audit Level (см. Рисунок 4).

    Рисунок 4. Установка аудита регистрации пользователей.

    Как записывать собственные сообщения в Error Log

    Собственные сообщения можно записать в журнал с помощью оператора RAISERROR или хранимой процедуры xp_logevent.

    В RAISERROR для записи в журнал используется параметр WITH LOG :

    Хранимая процедура xp_logevent специально предназначена для записи сообщений в Error Log:

    Первый параметр — код сообщения, он должен быть больше 50 000. Последний параметр может принимать значения INFORMATIONAL, WARNING или ERROR. Необходимо обратить внимание на то, что xp_logevent, в отличие от RAISERROR, не посылает сообщение клиентской программе и не изменяет значения глобальной переменой @@ERROR. Для xp_logevent также нужна настройка прав на выполнение.

    Хранимые процедуры для работы Error Log

    Хранимая процедура sp_enumerrorlogs служит для получения полного списка журналов с указанием даты окончания записи в них и их объема. Хранимая процедура sp_readerrorlog читает журнал с указанным номером. Если номер не указан или номер 0, читается текущий журнал. Результаты выполнения названных процедур приведены на Рисунке 5 .

    Обе процедуры возвращают в качестве результата таблицы, структуры которых приведены ниже при описании примера работы с Error Log. Хранимая процедура sp_cycle_errorlog служит для принудительного открытия нового файла журнала. Необходимость открыть новый файл журнала может быть вызвана, например, большим объемом текущего журнала в результате длительной непрерывной работы сервера (журнал большого объема трудно просматривать и анализировать).

    Пример практического использования знаний об Error Log

    Администратор базы данных должен знать, как часто происходит запуск и остановка SQL Server. Особенно эта информация полезна, если сервер физически расположен не в организации, а у провайдера услуг. При этом желательно знать общее время работы сервера и причины остановки. Сценарий, приведенный в Листинге 1 , решает эту задачу, используя информацию из Error Log.

    Итог исполнения сценария на тестовом сервере приведен на Рисунке 6 . Здесь показано, что первый, второй, пятый и шестой журналы были закрыты по причине остановки Windows, третий журнал — в результате остановки службы SQL Server, а четвертый — принудительно хранимой процедурой sp_cycle_errorlog.

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

    Ильдар Даутов — MCT, MCDBA, начальник отдела АКБ «Заречье», dia@zarech.ru.

    Поделитесь материалом с коллегами и друзьями

    Сервис событий в SQL-сервере. Диспетчер настроек SQL Server

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

    Более точно сказать было даже несколько проблем, которые, как обычно, наслоились друг на друга (или их “наслоили” администраторы пытавшиеся решить проблему).
    Статья не ставит перед собой целью всестороннее и подробнейшее описание всей системы Service Broker, со всеми ее возможностями.
    Здесь лишь описана среда, с которой я сталкивался наиболее часто в ходе решения проблем.
    Наверное все, кто читают данный блог знают, что такое Service Broker в SQL Server, но, для того чтобы начать с одной исходной точки, я скажу пару слов об этой штуковине.

    Впервые эта полезная вещь появилась в SQL Server 2005, и с тех пор не сильно изменилась. Точнее сказать она приросла некоторыми новыми возможностями, но принципы, заложенные в те годы, так и остались неизменными.
    Итак.
    Как следует из https://technet.microsoft.com/ru-ru/library/ms166049(v=sql.105). aspx, компонент Service Broker помогает создавать асинхронные слабосвязанные приложения, в которых независимые компоненты совместно выполняют ту или иную задачу. Эти компоненты обмениваются сообщениями, которые содержат данные, необходимые для выполнения задачи. В этом разделе описываются следующие аспекты компонента Service Broker:
    диалоги;

    • упорядочение и координация сообщений;
    • асинхронное программирование на основе транзакций;
    • поддержка слабосвязанных приложений;
    • составные части компонента Service Broker.

    Основными строительными кирпичиками системы являются:

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

    Моя тестовая среда включает в себя:

    • Два экземпляра SQL Server установленных на разных виртуальных машинах
    • Контроллер домена.
    • Точки доступа (Endpoints) настроены для использования Windows аутентификации.
    • На обоих серверах созданы пользователи без логинов, использующие сертификаты для взаимной аутентификации.
    • Сертификаты скопированы на оба сервера с использованием backup.

    Как это все работает вместе. Ниже приведена упрощенная схема обмена сообщениями и ее описание.

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

    Для просмотра сообщений, находящихся в очереди, во вне “выставлено” динамическое представление sys.transmission_queue, выполнив запрос к которому вы получите почти тот же результат. Однако в этом представлении есть очень полезный элемент, это столбец transmission_status, содержащий информацию об ошибке, возникшей при передаче и обработке сообщения.
    Например: “ Connection attempt failed with error: ‘10061(No connection could be made because the target machine actively refused it.)‘ .”
    Также сообщение логируется в журнале транзакций, что обеспечивает его транзактную обработку.

    Все сообщения от всех создаваемых сервисов проходят через эту внутреннюю таблицу и соответственно через просмотр, и при отсутствии ошибок передаются далее. Перед передачей сообщения могут шифроваться с использованием сертификатов. Будут сообщения шифроваться или нет зависит от настроек диалога инициирующего соединение.
    2. После помещения сообщения в очередь передачи (sys.transmission_queue) выполняется его классифицирование.
    Суть классификации состоит в том, чтобы определить, где размещен сервис, которому это сообщение адресуется. Для определения направления передачи используются маршруты доставки,созданные на этапе развертывания сервиса. В данном случае настроено два маршрута. Один указывает на удаленный сервис-получатель, другой указывает на локальный экземпляр SQL Server для доставки локальных оповещений.

    Мы можем увидеть выполнение этапа классификации с помощью трасс SQL Profiler, если выберем события относящиеся к Service Broker. Обращаю внимание, что часть событий относящихся к Service Broker размещены в разделе Security Audit.

    3. После выполнения классификации сообщения, устанавливается соединение с удаленной (как в данном случае) точкой соединения (Endpoint). В данном случае – это сервер использующий протокол TCP, с именем SQL2014-I1 и номером порта (Endpoint) 4022. Если при выполнении соединения возникнет ошибка, то она появится в трассе (как показано ниже) и в столбце transmission_status просмотра sys.transmission_queue.

    4. На следующем этапе происходит отправка сообщения сервису получателю и его подтверждение от принимающей стороны. Если на донном этапе выполнить запрос к представлению transmission_queue , то оно возвратит пустой результат, поскольку все данные из очереди отправителя переданы.

    В трассе на инициаторе и отправителе мы увидим подтверждение передачи.

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

    Далее, целевой сервис должен прочитать сообщения из очереди (желательно по одному) и отправить подтверждение о получении инициатору диалога. Делается эта процедура с использованием специального синтаксиса, который есть в прилагаемых скриптах https://technet.microsoft.com/en-us/library/bb839483(v=sql.105).aspx .
    По мере чтения данных из очереди она пустеет, а отправителю посылается подтверждающие сообщения (или не посылаются) форма, состав которых, а также посылаются они, или нет, зависит от разработчика сервиса.
    Если по мере чтения очереди программируется отправка подтверждающих сообщений, то они проходят тот же путь, что и от получателя, только в обратном порядке.
    В данном блоге мы достаточно подробно рассмотрели весь путь от отправителя до получателя и в следующем начнем рассмотрение вопросов связанных с решением проблем с Service Broker на каждом из этапов обработки и передачи..

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

    Вероятно, вы знаете, что обслуживание баз данных это целый комплекс процедур: создание бэкапов, проверка целостности, обслуживание индексов, статистики и т.д. На просторах сети (да и на Хабре в том числе) на эту тему написано множество статей и рекомендаций. Однако занимаясь внедрением «1С: Предприятие», нам частенько приходится сталкиваться с тем, что обслуживание баз данных настраивается либо неправильно, либо по очень упрощённой схеме. Например, чтобы не заморачиваться с управлением журналами транзакций, для «боевых» баз устанавливается Простая модель восстановления (Simple Recovery model). И это несмотря на то, что потеря информации за пару часов уже критична для компании. Иногда задача по сжатию файлов БД включается в регулярное обслуживание («шобы не росло»), или после обновления индексов идёт уничтожение статистики и прочие подобные ляпы. Так происходит потому, что чаще всего в компаниях нет опытного администратора БД и обслуживанием приходится заниматься кому-то из сотрудников ИТ-службы – «невольному» администратору баз данных (DBA). При этом такой DBA не всегда осознаёт все риски и возложенную на него ответственность.

    Для обслуживания баз Microsoft предлагает планы обслуживания (Maintenance Plan) в SQL Server Management Studio (SSMS). Однако как показывает практика, создать и настроить качественный и надёжный план обслуживания может только опытный DBA. Отмечу, что надёжное обслуживание максимально автоматизировано и не требует регулярного ручного мониторинга администратором, а также гарантирует, что данные удастся восстановить в случае сбоя.

    Сторонние программы, которые имеются на рынке и способны облегчить жизнь, в основном автоматизируют создание бэкапов. Выбор таких программ очень широк. Они позволяют делать бэкапы сжатые и шифрованные, на FTP/GoogleDrive/Amazon и так далее. Бэкапы тут можно сравнить с креветками, о которых говорил Бабба в картине «Форест Гамп»: «… их можно жарить, варить, печь, тушить, можно приготовить шашлык из креветок, креветки по-креольски, креветки гамбо, поджаренные с рисом … ».

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

    В итоге «невольному» DBA приходится читать статьи, разбираться с SSMS, разрабатывать стратегию резервного копирования, искать скрипты, настраивать уведомления. Времени уходит много, но всегда есть, что обматерить… А хочется жить безмятежно! Так, чтобы один раз сделал и забыл.

    В этой статье я хотел бы сделать обзор нашей программы Quick Maintenance & Backup (QMB), которая поможет вам просто и быстро настроить обслуживание баз данных на Microsoft SQL Server. Бесспорно, что для больших и высоконагруженных баз данных не обойтись без опытного DBA и индивидуального тюнинга производительности, но если вам приходится иметь дело с множеством небольших баз (как правило до 50-80 Гб), то данная утилита будет полезна как новичкам, так и продвинутым пользователям.

    Основные возможности QMB

    • Простая и быстрая настройка
    • Обслуживание нескольких SQL Server в одной программе. Поддерживаются SQL Server версий 2000 и старше, в том числе Express редакции
    • 30 встроенных задач с открытыми скриптами, в том числе популярные скрипты Ola Hallengren:

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

  • 7 предустановленных политик обслуживания для Полной и Простой модели восстановления

  • Мониторинг свободного места на дисках SQL Server
  • Пользовательские задачи на скриптовых языках Transact SQL, CMD, VBScript, JavaScript, PowerShell и других
  • Статистика изменения размеров баз данных. Расчёт среднего прироста данных
  • Уведомления по электронной почте
  • Подробный журнал обслуживания
  • В коротком видеоролике ниже показан сквозной пример настройки обслуживания с помощью QMB. Последующее описание дополняет видеоролик и рассказывает о некоторых особенностях программы.

    Концепция: доступно новичкам, удобно профессионалам

    Архитектура

    Политика обслуживания, сценарии и задачи

    Задача в QMB может иметь один из пяти типов:

    • Скрипт T-SQL
    • Создание архивной копии (скрипт T-SQL)
    • Восстановление архивной копии (динамический скрипт T-SQL)
    • Произвольный скрипт (не T-SQL)
    • Копирование архивных копий (используется в одноименной системной задаче)

    В программе имеется два набора встроенных задач. Первый набор задач базируется на T-SQL скриптах, полученных из открытых источников и созданных разработчиками QMB. Второй набор базируется на скриптах Ола Халенгрэн (администратор баз данных из Швеции), который разработал три популярные хранимые процедуры для обслуживания баз данных. Процедуры Ола устанавливаются автоматически в системную базу данных master, при создании политики из шаблона.

    Обслуживание больших и маленьких баз данных. Шаблоны политик

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

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

    Задачи

    Исполнение скриптов

    Тексты скриптов (T-SQL, CMD, VBS, PowerShell и других) могут содержать маркеры, которые будут заменены на соответствующие значения, перед его исполнением. Например, маркер ?DataBaseName? будет заменён на имя базы данных, а маркер ?BackupDirectory? – на путь к каталогу архивных копий, указанному в политике. Полный список маркеров можно посмотреть в справке .

    Оптимизация окна обслуживания
    Бывает, что в ограниченное временное окно необходимо уместить не только обслуживание баз средствами SQL Server, но и исполнение других регламентных операций вашего приложения. Например, тестирование и исправление баз 1С, выгрузку средствами платформы «1С: Предприятие», проведение обмена и т.п. Обычно для этого используется планировщик заданий Windows или планировщик «1С: Предприятие». Однако при этом приходится разносить процедуры во времени с хорошим запасом – так, чтобы они гарантированно не пересекались. В итоге задачи могут не уложиться в имеющееся временное окно.

    С QMB можно максимально эффективно использовать окно обслуживания, объединив в сценарии исполнение T-SQL скриптов и пакетных файлов на языках VBS, JavaScript, CMD, PowerShell и других. Ниже показан простой пример задачи альтернативного копирования бэкапов с помощью утилиты Robocopy:

    Нужно отметить, что пакетный файл может выполняться как на машине, где установлена программа, так и на стороне SQL Server. Это позволяет оперировать файлами бэкапов на стороне SQL Server. Например, можно написать скрипт, который будет архивировать последний бэкап и выкладывать его в любое облачное хранилище или реализовать собственный алгоритм копирования. В следующих статьях я планирую подробнее рассказать об этой возможности и привести скрипты для работы с базами «1С: Предприятие 8».

    Вывод сообщений и журнал обслуживания
    Все сообщения, выводимые при исполнении скрипта, перенаправляются в журнал обслуживания программы. Это касается сообщений, выводимых командами print, raiserror для T-SQL скриптов, а также сообщений, выводимых в консоль командами echo, для прочих CMD-скриптов и пакетных файлов. И это здорово! Потому что читабельные и понятные логи – это колоссальная экономия времени, а в качестве бонуса – текст ошибок отправляется в email-уведомлении.

    Автоматизированная проверка бэкапов через восстановление

    В QMB имеется специальная задача, которая последовательно восстановит всю цепочку бэкапов для каждой базы данных политики: Full backup –> Differential backup –> Transaction log backup. Восстановление выполняется во временную тестовую базу, которая удаляется после проверки её целостности.

    Например, у нас в компании на виртуальном SQL Server имеется около 60 небольших баз данных, общим объёмом под 100 Гб. QMB каждую ночь выполняет проверку возможности восстановления всех баз. Проверка занимает около полутора часов и это даёт нам гарантию того, что все резервные копии проверены. Если цепочка бэкапов будет прервана, то придёт уведомление с примерно такой ошибкой:

    1. Задача «Восстановление из арх. копий во временную БД с последующей проверкой целостности» (база данных: Buh_Oazis)

    Советы тем, кто захочет настроить подобную проверку:

    1. Операция восстановления ресурсоемкая, поэтому её следует включать в сценарии исполняемые только в нерабочее время.
    2. Для создания временной тестовой базы и восстановления бэкапов в неё требуется запас дискового пространства, равный как минимум самой большой базе данных в политике + 10% от её объёма.
    3. Восстановление больших баз может занимать значительное время. Не включайте задачу по проверке, если не уверены, что операция успеет завершиться в отведённое окно обслуживания.
    4. Правильно размещайте задачу в сценарии. Учитывайте, что восстановление выполняется на актуальный момент времени, т.е. на момент исполнения задачи. Например, если задачу проверки бэкапов разместить сразу после создания полной резервной копии, то будет протестирован только последний бэкап, т.к. его будет достаточно для восстановления базы на актуальный момент времени.
    5. Если на проверку бэкапов всех баз политики не хватает окна обслуживания, можно проверять бэкапы только определённых баз данных. Либо распределить задачи по дням недели. Например, сегодня ночью проверить бэкапы баз А и B, а завтра – баз C и D.
    6. Не рекомендуется делать бэкапы в сетевую папку, т.к. при восстановлении приходится «тащить» файлы бэкапов по сети, что значительно увеличивает время восстановления. Правильнее будет настроить создание бэкапов на локальный диск с ежедневным копированием в сетевую папку.

    Автоматизированная поддержка копий баз в актуальном состоянии

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

    Копирование файлов бэкапов

    Ниже я хотел бы акцентировать внимание на нескольких особенностях копирования бэкапов c помощью QMB:

    1. Частота копирования определяется расписанием сценария, содержащего задачу «Копирование архивных копий». Задачу можно разместить в одном или нескольких сценариях.
    2. Копируются только новые и изменённые файлы бэкапов – это снижает нагрузку на сеть и позволяет выполнять частое копирование. Например, можно копировать каждый раз после создания нового бэкапа журнала транзакций.
    3. Для сетевой папки можно задать срок хранения файлов. Таким образом, на локальном диске SQL Server можно хранить бэкапы, например, за 1 неделю, а в сетевой папке за 1 месяц.
    4. Возможно настроить копирование бэкапов только для избранных баз политики.

    Восстановление баз данных

    Команда «Восстановление из архивной копии» позволяет:

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

    Оповещения на Email

    ЗАДАНИЕ ВЫПОЛНЯЕТСЯ:
    «Рабочие базы данных.ВложенныйПлан_1» началось в 19.05.2015 17:00:00
    ДЛИТЕЛЬНОСТЬ:
    0 час., 0 мин., 5 сек.
    СОСТОЯНИЕ:
    Ошибка
    СООБЩЕНИЯ:
    Не удалось завершить задание. Запуск задания был произведен Расписание 9 (MaintenancePlan). Последним выполнявшимся шагом был шаг 1 (Бэкап журнала транзакций).

    В отличие от Database Mail, QMB отправляет в уведомлении первые 15 строк текста ошибки. Обычно этого бывает достаточно, чтобы понять причину и предпринять нужные действия. Посмотреть полный лог можно в журнале обслуживания программы. Пример сообщения с ошибкой:

    Сценарий «Ресурсоемкие задачи для средних OLTP баз (каждую ночь)» был выполнен с ошибками на сервере «Srv05».

    Старт сценария: 06.06.2015 1:00
    Окончание работы: 06.06.2015 1:29
    Длительность: 00:29:28

    Всего задач: 7
    Выполнено задач: 7
    С ошибками: 1

    1. Задача «Восстановление из арх. копий во временную БД с последующей проверкой целостности» (база данных: IPGor)
    Message: 4305, Level: 16, State: 1, Line: 21
    Журнал в этом резервном наборе данных начинается с номера LSN 5235000000291100001, который еще не может применяться к базе данных. Может быть восстановлена более ранняя резервная копия журналов, включающая номер LSN 5228000000281600001.

    Message: 3013, Level: 16, State: 1, Line: 21
    RESTORE LOG прервано с ошибкой.

    Message: 50000, Level: 16, State: 1, Line: 119
    В процессе восстановления возникла ошибка

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

    Лицензионная политика и стоимость

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

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

    Заключение

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

    Спасибо за внимание, готов ответить на ваши вопросы в комментариях.

    Теги: Добавить метки

    Итак в продолжении темы обслуживания баз 1С присмотримся к системе управления реляционными базами данных Microsoft SQL Server. Этот продукт предоставляет нам большие возможности обработки, хранения, резервирования и восстановления баз. Я начну небольшой цикл статей, посвященных этой теме. Все, что будет написано ниже, является личным мнением по данному вопросу и подлежит критике.

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

    В тестовой лаборатории у нас следующее:

    • Сервер Windows Server 2008 Enterprise: SRV-1C-TEST .
    • Microsoft SQL Server 2008: SRV-1C-TEST .
    • Тестовая база BuhFirma .

    Как обычно, поставим перед собой задачу:

    Проводить обслуживание базы в период 00:30 — 01:00, при этом обслуживание не должно быть заметным (либо слабозаметным) для пользователей базы.

    Начнём с важных моментов. MS SQL база данных может иметь один из трех типов модели восстановления:

    • Простая.
    • Полная.
    • С неполным протоколированием.

    Так же при резервном копировании нам предоставляется на выбор три варианта копирования:

    • Полное.
    • Разностное.
    • Копирование журнала транзакций (логов).


    При полном варианте копирования происходит сохранение базы mdf и журнала транзакций. Разностное копирование (по-другому дифференциальное) производит копирование данных, изменившихся с момента создания последней полной резервной копии. Копирование журнала транзакций соответственно производит сохранение только самого журнала транзакций.

    При выборе простой модели восстановить базу данных можно с момента создания последней разностной или полной резервной копии. При выборе полной модели восстановления мы можем восстанавливать базу до минуты, создав полную резервную копию, например, ночью, и в течение дня создавать копии журнала транзакции. Ниже мы увидим, где всплывает этот момент. Хотелось так же привести некоторые выдержки из MSDN : «Модель восстановления с неполным протоколированием предназначена исключительно как дополнение к модели полного восстановления. В общем случае модель восстановления с неполным протоколированием похожа на модель полного восстановления, за исключением того, что протоколирование большинства массовых операций в ней производится в минимальной степени».

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

    В MSSQL 2008 по умолчанию в созданных базах данных модель восстановления Полная .

    Как выбрать модель восстановления? Надо лишь ответить на вопрос: смертельна ли потеря информации за время, прошедшее после полного резервного копирования? Если ответ да, тогда выбираем полную модель восстановления, если нет, простую. Модель с неполным протоколированием стоит применять только на время массовых операций в БД.

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

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

    • Проверка целостности базы
    • Перестроение индекса
    • Обновление статистики
    • Очистка процедурного кэша СУБД
    • Резервное копирование базы данных
    • Очистка после обслуживания
    • Очистка журнала

    Для этого подключимся к MSSQL серверу с помощью среды Microsoft SQLServer Management Studio . Запустить среду можно перейдя в Пуск — Все программы — Microsoft SQL Server 2008 .

    Подключимся с серверу SQL и перейдем в Управление — Планы Обслуживания . Кликнем правой кнопкой по Планы обслуживания и выберем Создать план обслуживания . Дадим ему имя: SRV1CTEST .

    Перед нами окно SRV1CTEST, в котором мы и будем создавать последовательность действий, обозначенных раннее. Сразу видим появившейся Вложенный_План1 . Справа от названия вложенного плана вы увидите иконку в виде таблички. Нажимаем на нее и попадаем в свойства расписания задания. Здесь можно менять название вложенного плана, выставить частоту повторения в Ежедневно и установить время. И так теперь осталось наполнить наш план заданиями. Для этого с Панели инструментов, которая находится справой стороны, перетаскиваем задания.

    Начнем с Проверки целостности базы данных .

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

    Процедура Перестроение индекса пересоздает индекс с новым коэффициентом заполнения. За счет этого мы увеличиваем производительность работы в БД.

    Задача Обновление статистики обновляет сведения о данных таблиц для MS SQL. Что тоже повышает производительность. Но после этой операции надо обязательно проводить очистку кэша.

    Пока остановимся и поговорим о настройке связей между заданиями. Связи отражают последовательность выполнения. Что бы провести связь между заданиями надо нажать один раз на задание и увидите появившуюся стрелку. Её надо перетащить на следующее задание. У связи может быть 3 цвета: синий, зеленый и красный, каждый из которых означает три типа срабатывания перехода: при простом завершении предыдущего задания — Завершение , в случае успешного завершения — Успех , а в случае возникновения ошибки при выполнение предыдущего задания — Ошибка . Все эти параметры вы можете увидеть, нажав правой кнопкой мыши на проведенную между заданиями стрелку. Таким образом, если нам надо, чтобы Перестроение индекса срабатывало только после успешного завершения задания Проверка целостности базы данных , мы должны связать их стрелкой. Нажав правой кнопкой мыши на стрелку, сменим ее режим на Успешно , как видим, ее цвет изменился на зеленый.

    На данный момент мы имеем 3 созданных задания в нашем вложенном плане. Как вы могли заметить, задания Очистка процедурного кэша СУБД в панели элементов нету. Мы воспользуемся задачей Выполнение инструкции T-SQL . Перетащим ее в план, и щелкнем на ней два раза. Мы видим окно, в которое впишем следующее:

    В SQL Server 2020 и более поздних версиях можно установить все компоненты, связанные с Службы 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 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 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.

    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-сервере

    Расширенные события (xEvents) — это упрощенная система трассировки и мониторинга производительности, которая использует очень небольшое количество системных ресурсов. Это делает систему идеальным средством для диагностики проблем как на производственных, так и на тестовых серверах. Система также характеризуется высокой масштабируемостью и возможностями настройки. В SQL Server 2020 ее использование упрощено благодаря поддержке новых встроенных средств. В SQL Server Management Studio для подключений к экземплярам служб Analysis Services можно настроить, запустить и отслеживать динамическую трассировку так же, как и при использовании приложения SQL Server Profiler. Добавление улучшенных средств не только делает xEvents более рациональной заменой SQL Server Profiler, но и позволяет упорядочить диагностику проблем в ядре СУБД и рабочих нагрузках служб Analysis Services.

    Кроме использования SQL Server Management Studio вы также можете настроить сеансы расширенных событий Службы Analysis Services традиционным способом — с помощью скриптов XMLA, поддерживаемых в предыдущих выпусках.

    Все события служб Analysis Services можно регистрировать и направлять конкретным получателям, как определено в расширенных событиях.

    Просмотрите это краткое вводное видео или прочитайте публикацию в блоге службы поддержки, чтобы узнать больше о расширенных событиях xEvents для служб Analysis Services в SQL Server 2020.

    Настройка служб Analysis Services с помощью Management Studio

    Скрипт XMLA для запуска расширенных событий в службах Analysis Services

    Как для табличных, так и для многомерных экземпляров Management Studio предусматривает новую папку «Управление», содержащую инициированные пользователем сеансы xEvent. Одновременно можно запускать несколько сеансов. Однако в текущей реализации пользовательский интерфейс расширенных событий Службы Analysis Services не поддерживает обновление или воспроизведение существующего сеанса.

    Выбор событий

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

    CommandBegin и CommandEnd.

    QueryBegin, QueryEnd и QuerySubcubeVerbose (показывает весь запрос MDX или DAX, отправляемый на сервер), а также ResourceUsage для статистики по ресурсам, потребленным запросом, и количеству возвращенных строк.

    ProgressReportBegin и ProgressReportEnd (для операций обработки).

    AuditLogin и AuditLogout (фиксирует идентификатор пользователя, под которым клиентское приложение подключается к службам Analysis Services).

    Выбор хранилища данных

    Сеанс может передаваться в виде потока в окно Management Studio или сохраняться в файл для последующего анализа с помощью Power Query или Excel.

    event_file сохраняет данные сеанса в XEL-файле.

    event_stream включает параметр Просмотр данных, передаваемых в режиме реального времени в среде Management Studio.

    ring_buffer сохраняет данные сеанса в памяти, пока работает сервер. При перезапуске сервера данные сеанса теряются.

    Добавление полей событий

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

    Параметр Настроить находится в удаленной области диалогового окна.

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

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

    Обновление сеансов

    После создания сеанса не забудьте обновить папку «Сеансы» в Management Studio для просмотра сеанса, который вы только что создали. Если вы настроили event_stream, можно щелкнуть правой кнопкой мыши имя сеанса и выбрать Просмотр динамических данных для мониторинга активности сервера в режиме реального времени.

    Расширенная трассировка событий включается с помощью команды скрипта создания объекта, аналогичной команде XML для аналитики, как показано ниже.

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

    trace_id
    Определяет уникальный идентификатор для данной трассировки.

    trace_name
    Имя, присвоенное данной трассировке. Как правило, понятное определение трассировки. Обычно принято использовать в качестве имени значение trace_id.

    AS_event
    Событие служб Analysis Services, к которому должен быть предоставлен доступ. Имена событий см. в разделе События трассировки служб Analysis Services.

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

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

    Примечание
    В этом разделе

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

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

    trace_id
    Определяет уникальный идентификатор удаляемой трассировки.

    Брокер служб SQL Server 2005: Создание сообщений технологии корпорации Майкрософт расположенную

    Olamendy Turruellas Juan Карлос (John Чарльз)

    В SQL Server 2005 Корпорация Майкрософт представила технологию Service Broker (SSB), которая поддерживает шаблон разработки брокера и принципы ориентированных на сообщения по промежуточного слоя (MOM). Эта технология тем не менее, был немного использован, несмотря на возможность SSB, в отличие от традиционных синхронный запрос ответ подход, позволяющие разработчикам создавать надежные, масштабируемые, распределенных и асинхронного обмена сообщениями приложения путем реализации механизмов очереди сообщений, которые объединяются с возможностями реляционной базы данных SQL Server.

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

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

    Применение SSB с бизнес-сценарием реальном мире

    Основной контекст, в котором можно применить технологию SSB находится в разработке решения интеграции для корпоративных приложений. Эти приложения обычно поддерживают управление и автоматизацию бизнес-процессов, требующих промежуточного надежного ориентированных на сообщения по (не сообщения будут утеряны) для обмена данными между ними. Кроме того эти приложения находятся в сложной среде с большим числом систем и пользователей. Не все приложения являются сети в одно и то же время, и их обработке запросов в слабо связанных способ может занять много времени.

    В модели традиционных запрос ответ является синхронной связи между серверными системами и бизнес-логику процесса реализуется (используя высокого уровня языка, например C# или Java) через компоненты бизнес-слой решения и как ряд операций базы данных. Если один обслуживающей системе вниз, в этот подход весь процесс передает ждущего режима состояние. Например кредитной карты не может авторизовать Если система оплаты вниз.

    Основной целью SSB приложений является интеграция корпоративных систем через общий канал связи. Некоторые внешних приложений (ERP, управление цепи поставок, CRM и других) или внутренних модулей (код T-SQL и CLR управляемых триггеров и хранимых процедур), помещение сообщения в очереди, во время их аналоги получать уведомления, сообщения находятся в очереди (и необходимость извлечения и выводе из очереди) через триггера или обычные операции SEND и получения. Здесь концепция основана на корпоративной системы которого серверные компоненты могут принимать запросы немедленно, но отложить обработку запросов, возвращая информационное сообщение клиенту, указывающее, что он должен ждать ответа позже.

    Асинхронные SSB решение примера показано в этой статье (см. рис. 1) включает узла портала и базы данных хранилища и запасов. Узла портала, имеет два веб-страницы: один для ввода данных, связанных с запросом заказа и другой для просмотра статуса заказа. Приложения базы данных хранилища получает запросы заказа от узла портала, сохраняет эти данные в таблице tbOrder и отправляет данные запроса заказа в форме сообщений в очереди на общие шины в канал связи, прослушивает приложения базы данных запасов. База данных запасов получает входящий запрос заказы и обрабатывает Склад хранения и распространения доставки. Также создает основной порядок ответа и отправляет его, используя другой очереди для базы данных хранилища. Наконец базы данных хранилища прослушивает заказа ответные сообщения и обновляет состояние основной порядок запроса строки (ОК или НЕДОПУСТИМЫЙ статус) в tbOrder таблицы, который позволяет пользователям проверять состояние заказов. Таким образом распределенных решение делегирует все процедуры обмена сообщениями, резервного копирования, администрирования и отказоустойчивого инфраструктуру SSB (Применение шаблона разработки Broker) и сосредоточено его усилия на домене проблемы.

    Рисунок 1 электронной коммерции сценарий как составной решений из корпоративные системы

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

    Рисунок 2 SSB архитектуры решения

    Как проанализировать архитектуру решения SSB может распознать, что базового решения интеграции может понял технологии других обмена сообщениями, такие как MSMQ и Microsoft BizTalk Server. Однако Microsoft SQL Server вместе с компонент Service Broker предоставляет надежную инфраструктуру для создания комплексных приложений и имеет уровень восстанавливаемости, сопровождаемость, надежность, производительность и масштабируемость можно найти в системе базы данных. Средства качество обновления в SSB относятся следующие:

    • Транзакции. Если сообщение извлекается из очереди и возникает ошибка, сообщение не теряются.
    • Возможности восстановления. Если в системе происходит сбой из-за сбоев носителей, проблемы в процессора или в оперативной памяти или в системе подвергается длительного отключения электричества, сообщения должны сохраняться долговременной основе продолжить обработку при ее восстановлении системы.
    • Масштабируемость. После учета сообщения в очередь они обрабатываются скоростью, не предоставляет проблем с производительностью при добавлении дополнительных ресурсов. Рабочая нагрузка может увеличиваться многие тысячи сообщений в секунду, но рабочей нагрузки может быть сбалансирована путем распределения работы между много участников SSB экземпляров.

    Реализация решения


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

    Первым шагом является для включения функций компонента Service Broker и безопасность транспорта в обеих базах данных (см. рис. 3) путем настройки базового уровня экземпляров в системном каталоге (базы данных master).

    Включение SSB на рис. 3 и средства безопасности транспорта в участие базы данных

    Как отслеживать изменения в DB MS SQL 2008 на C# через Service Broker?

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

    • Приложение, написанное на C#
    • SQL Server, с базой данной на 3 таблички

    В программе делаю следующее:

    Кусок для SqlDependency писал по этому примеру

    В самой бд сделал ALTER DATABASE [Database_name] SET ENABLE_BROKER;

    Но. по какой-то причине, по ПКМ->Свойства->Отслеживание изменений в поле Отслеживание изменений висело False. Ну, ручками переключил на True.

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

    У меня появилось ряд вопросов, в ходе изучения матчасти.

    1) Queue. Как узнать имя моей очереди по дефолту. Как её конфигурировать? Потому что, как я понял, у меня не совсем полный код для SqlDependency, т.к. требуется

    но queueName я не знаю.

    2) Мне нужно только узнавать о том, были изменения или нет. Какие конкретно, мне не важно, и непонятно для чего в примере висит этот кусок:

    Точнее как, понятно, что по идее по правильному я должен подтянуть те самые изменения из Queue и уже дальше работать с ними, к примеру, ими заполнить ячейку в гриде, а не заполнять заново весь грид (но он у меня мелкий и особо я не теряю от Fill), но, вероятно, это что-то нужное, раз у меня не влзелето?

    3) Как в SQL SMS проверить работает ли вообще Service Broker? Я читал про сообщения в бд, на которые должен, якобы, ответить Service Broker, но конкретного ничего не вычитал (что он должен ответить, в какой форме, куда, как смотреть этот пакет в таком случае).

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

    Поиск причин ожиданий (waits) на вашем SQL Server

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

    К сожалению, нет лёгкого ответа на вопрос «Какие именно запросы вызывают те или иные ожидания», но мы можем собирать информацию по частям.

    Поиск причин ожиданий (waits) на вашем SQL Server

    Ожидания сессий

    Кроме описанного выше способа получения общего списка ожиданий вашего SQL Server, нам может понадобится информация о последних ожиданиях сессии. В этом нам поможет поле lastwaittype из SYSPROCESSES:

    Так же мы можем очистить представление sys . dm_os_wait_stats и собрать данные за нужный нам промежуток времени, начиная с момента чистки. Очистить sys . dm_os_wait_stats можно с помощью следующего кода:

    В SQL Server 2020 появилось новое, полезное представление sys.dm_exec_session_wait_stats. Оно содержит суммарную информацию по всем ожиданиям сессии. Обратите внимание, что при отключении сессии информации обнуляется.

    Extended Events

    Расширенные события позволят исследовать ожидания всех запросов, а не их части, что значительно облегчит наш поиск, но у них есть 2 особенности:

    1. У Расширенных событий нет графического интерфейса до SQL Server 2012, необходимо будет освоить управление с помощью t-sql команд
    2. На высоконагруженной системе файл вывода может очень быстро увеличится в размерах, чтобы этого избежать собирайте только нужную информацию и используйте фильтры

    Из-за большие затрат на сбор Extended Events, рекомендуется собирать их в определённое временное окно и исследуя определённые типы ожиданий. Крайней не рекомендуется использовать их для регулярного мониторинга.

    Наиболее часто встречающиеся виды ожиданий

    CXPACKET waits

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

    PAGEIOLATCH_XX waits

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

    LCK_M_XX waits

    Ожидания блокировок. Иногда для решения этих ожиданий вам поможет «blocked process report». Так же вы можете посмотреть бесплатный курс Troubleshooting Blocking and Deadlocks for Beginners (англ).

    Более редкие типы ожиданий

    RESOURCE_SEMAPHORE waits

    Этот тип ожиданий ассоциируется с малым «query workspace memory» и со стороны это может выглядеть как будто SQL Server не работает. Тем не менее вы по прежнему можете использовать выделенное административное подключение для изучения проблемы.

    Так же вам поможет счётчик производительности Manager\Memory Grants Pending (количество процессов, которые ожидают выделения памяти). Вы можете настроить Alert на SQL Server Agent для данного счётчика, который будет собирать информацию о текущей активности сервера в таблицу.

    THREADPOOL waits

    Ожидания связаны с недостаточностью потоков (threads). Это означает, что на сервере много активных процессов, так много, что SQL Server не может больше их выделить без риска нарушения стабильности OS. Это может быть связано с проблемами пула подключений или приложением, которое не корректно завершает подключения или создаёт их чрезмерное количество.

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

    Вы так же можете воспользоваться Alert на SQL Server Agent для следующего счётчика производительности — General Statistics\Processes Blocked и собрать нужную информацию.

    Вывод

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

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

    Если вы используете SQL Server 2020+, вам сильно поможет механизм Query Store.

    SQL сервер

    Общие сведения o SQL сервере

    SQL сервер — программа, которая предназначена для хранения базы данных и обеспечения доступа к этим данным из других программ. В SQL Server включена поддержка языка XML и протокола HTTP, средства повышения быстродействия и доступности, позволяющие распределить нагрузку и обеспечить бесперебойную работу. Сложный доступ к данным используется для надежности их хранения. SQL сервер позволяет резервное копирование в любой момент рабочего дня без отключения пользователей. Также если размер вашей базы данных стремиться к гигабайту и продолжает увеличиваться, то SQL сервер единственно возможный метод обеспечения ее функционирования.

    Существует несколько способов подключения к SQL Server. Чаще всего используют четыре варианта:

    подключение по OLE DB — набор интерфейсов, основанных на СОМ, которые позволяют приложениям обращаться к данным, хранимым в разных источниках информации или хранилищах данных с помощью унифицированного доступа. Этот способ является наиболее рекомендуемым и современным вариантом;

    подключение по Open DataBase Connectivity (ODBC) — интерфейс взаимодействия приложений с системами управления базами данных (СУБД);

    подключение с использованием BDE (Borland Database Engine) — доступ к базам данных из C++ Builder, Delphi;

    подключение по JDBC, который позволяет приложениям под управлением Java соединяться с Microsoft SQL Server.

    Установка SQL сервера 2000

    Перед началом установки вставьте CD с Windows SQL 2000 в CD-ROM и запустите любой из менеджеров (Windows Explorer, Total Commander). Найдите в каталоге CD найдите Setup.bat и запустите его.

    Перед Вами стартовое окно. Опция “Install Database Server” позволяет начать процесс установки сервера SQL 2000. Для этого нажимаем Next. Существует три варианта установки SQL, выберите необходимый:

    Local Computer– установка сервера SQL на локальный компьютер;

    Remote Computer – установка сервера SQL на удаленный компьютер по сети;

    Virtual Server – установки сервера SQL в кластер серверов.

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

    Выбираем следующие опции:

    Create a new instance, or install Client Tools – позволяет установить новый экземпляр сервера SQL и инструменты клиента (Client Tools)

    Upgrade, remove, or add components – позволяет работать с уже установленным экземпляром.


    Advance options – позволяет создавать индивидуальные установочные файлы, восстанавливать ключи регистра и поддерживать Виртуальные Серверы.

    Мы выберем Create a new instance, or install Client Tools и нажмем Next.

    В полях Name и Company вводим имя и компанию, нажимаем Next. Когда перед Вами появится окошко с правилами использования, нажимаем Yes (да, мы согласны с условиями лицензии).

    Теперь следует выбрать тип инсталляции.

    Client Tools Only — установить клиентскую часть для работы с удаленным SQL сервером.

    Server and Client Tools — установить клиентскую часть и SQL сервер на одном компьютере.

    Connectivity only – установить Data Access Components (DAC) и Сетевые библиотеки (Network Libraries), так чтобы приложения могли получать доступ к экземпляру сервера SQL.

    Если у Вас в сети уже есть установленный «удаленный» SQL сервер, выбирайте Client Tools Only, иначе — Server and Client Tools. Нажимаем Next.

    Необходима помощь специалистов? Оставьте заявку. Мы с Вами свяжемся.

    Если выбран режим Default, то сервер SQL будет установлен как экземпляр по умолчанию. Но если Вы хотите, Вы можете установить именованный экземпляр. Для этого выключите переключатель Default и введите имя экземпляра в поле Instance Name. Нажимаем кнопочку Next.

    Теперь определим объем инсталляции.

    Typical – установка обязательных файлов и наиболее часто используемых необязательных файлов.

    Minimum – установка только обязательных файлов.

    Custom – можно самостоятельно определить, какую конфигурацию SQL сервера Вы желаете установить.

    Так же нужно выбрать папки для Program Files и Data Files, в которые будет производиться инсталляция. Next.

    Сервер SQL 2000 использует две учетные записи: для агента сервера (Server Agent) SQL и для самого сервера SQL. Теперь пора определиться: использовать ли одну и ту же учетную запись для обеих служб или же будут созданы отдельные учетные записи для каждой службы отдельно. Если Вы будете использовать только одну учетную запись, тогда нужно еще выбрать, будет она локальной учетной записью (local system account) или учетной записью пользователя домена (domain user account). Если Вы пользуетесь только одним сервером SQL в сети, и Вы не планируете его взаимодействие с другими серверами SQL или удаленными серверами, Вы можете использовать только локальную учетную запись. Для примера выберем “Use the same account for both services. Autostart SQL Server Agent Service”, “Use the Local System account”.

    Режим аутентификации для доступа к базам данных может осуществляться операционной системой либо сервером SQL. Лучше вариант “Windows Authentication Mode”, при котором все идентификации обрабатываются через систему безопасности Windows для пользователей и групп.

    Выбор способа сортировки символов (collation) по умолчанию. Выберите “SQL Server Collations”, “Dictionary order, case-insensitive, for use with 1252 Character Set”, а затем нажмите Next.

    Теперь выберите сетевые библиотеки. Сохраните настройки по умолчанию и нажмите кнопку Next.

    После возникновения в окошке надписи «Setup has enough information to prompt you for the licensing mode information and start copying the program files. Click Back to review or change the settings, otherwise click Next to proceed.» Чтобы продолжить установку, нажмите Next.

    Введите тип и число лицензий, которые вы приобрели и нажмите кнопку Continue.

    Установка благополучно завершена.

    Теперь, чтобы найти инструменты, которые используются для работы с сервером SQL, щелкните мышью на кнопке Start на панели инструментов и выберите меню Programs и Microsoft SQL Server.

    Установка SQL сервера 2005

    Некоторые действия для установки сервера SQL 2005 совпадают с теми, которые мы выполняем при установке сервера 2000. Но, во избежание каких-либо проблем, давайте рассмотрим установку SQL сервера 2005 с самого начала до конца.

    Сначала запустите программу-установщик. Перед Вами возникнет стартовое окно. Нажимаем кнопку Далее.

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

    Регистрация сведений. Вам необходимо заполнить поле «Имя», поле «Компания» можно не заполнять. Нажимаем кнопку Далее.

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

    Как и при установке SQL сервера 2000 можно создать именованный экземпляр или экземпляр по умолчанию. Если Вы хотите установить именованный экземпляр, введите в поле ввода его имя. Нажмите Далее.

    Настраиваем учетные записи служб. Если Вы хотите настроить каждую учетную запись отдельно, поставьте соответствующий флажок. Выберите тип учетной записи и службы, которые будут запущены, после установки. Нажмите Далее.

    При установке SQL сервера нужно выбрать режим авторизации «Mixed Mode» (Смешанный режим (режим проверки подлинности Windows и режим проверки подлинности SQL Server)). Также необходимо установить пароль для учетной записи «sa». Нажмите Далее.

    Необходима помощь специалистов? Оставьте заявку. Мы с Вами свяжемся.

    Определяем режим сортировки данных для сервера. Порядок сортировки следует установить как «Cyrillic_General». Ставим галочку на пункте «С учетом диакритических символов» (по умолчанию уже стоит). Нажмите Далее.

    Теперь настраиваем параметры конфигурации. Если Вы поставите галочку на Включить пользовательские экземпляры, тогда пользователи, которые не имеют разрешение администратора, смогут запустить отдельный экземпляр компонента SQL Server. Если установить галочку на Добавить пользователя к роли «Администратор SQL Server«, тогда пользователь, который запустил программу установки SQL Server Express, будет добавлен к роли «Системный администратор». Нажмите Далее.

    Если Вы хотите помочь корпорации Майкрософт улучшить некоторые компоненты и службы SQL Server 2005, можете отметить галочками интересующие Вас пункты. Понятное дело — это не является обязательным. Нажимаем Далее.

    Когда появится окошко с сообщением «Все готово для установки», нажмите Установить.

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

    После завершения установки программы, нажмите Готово.

    Вот в общем-то и все) Удачи при установке.

    Установка SQL сервера 2008

    Установка SQL сервера 2008 имеет свои особенности, поэтому мы не будем останавливаться только на отличиях от установки сервера 2005, а пройдем с Вами весь путь.

    Запустите программу-установщик с правами администратора.

    В разделе «Планирование» нажмите пункт «Средство проверки конфигурации» (на рисунке обычно изображен молоточек и гаечный ключ).

    Теперь нажмите кнопку «Показать подробности» и убедитесь, все ли проверки пройдены успешно. Если были обнаружены какие-либо проблемы, необходимо их устранить и запустить проверку, нажав «Включить заново». Нажмите ОК.

    Далее заходим в раздел «Установка». Выбираем пункт «Новая установка изолированного SQL Server или добавление компонентов к существующему экземпляру».

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

    Введите приобретенный ключ продукта (если версия бесплатная, ключ не требуется) и нажмите Далее.

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

    Для установки файлов поддержки программы установки нажмите Установить.

    Нажмите кнопку «Показать подробности» и убедитесь, все ли проверки пройдены успешно. Если были обнаружены какие-либо проблемы, необходимо их устранить и запустить проверку, нажав «Включить заново». Нажмите ОК.

    На данном этапе выберите компоненты для установки (можно использовать кнопку «Выделить все») и нажмите Далее. Обратите внимание, что для нормальной работы ПО следует установить Полнотекстовый поиск и для управления самим SQL сервером необходимо выбрать Средства управления — основные.

    Выберите опцию «Экземпляр по умолчанию» или «Именованный экземпляр». Во втором случае задайте имя экземпляра. Нажмите Далее.

    Проверьте данные по месту на диске для компонентов SQL сервера и нажмите Далее.

    Выберите опции, как показано ниже, и перейдите на закладку «Параметры сортировки».

    Определяем режим сортировки данных для сервера. В обоих случаях следует установить «Cyrillic_General». Нажмите Далее. Чтобы изменить опцию, нажмите расположенную рядом кнопку «Настройка» и установите необходимые параметры (порядок сортировки следует установить как «Cyrillic_General» и поставить галочку на пункте «С учетом диакритических символов»).

    Теперь выберите опцию «Смешанный режим» и задайте пароль для учетной записи администратора «sa». Можно указать и дополнительные учетные записи пользователей Windows. Далее перейдите на закладку «Каталоги данных».

    Введите путь к папке, в которой будут размещены файлы баз данных, в поле «Корневой каталог данных». Нажмите кнопку Далее.

    Теперь задаем режим настройки служб Reporting Services. Выберите Установить конфигурацию по умолчанию для работы в собственном режиме и нажмите Далее.

    Если Вы хотите помочь корпорации Майкрософт улучшить некоторые компоненты и службы SQL Server 2008, можете отметить галочками интересующие Вас пункты. Понятное дело — это не является обязательным. Нажмите Далее.

    Нажмите кнопку «Показать подробности» и убедитесь, все ли проверки пройдены успешно. Если были обнаружены какие-либо проблемы, необходимо их устранить и запустить проверку, нажав «Включить заново». Нажмите ОК.

    Нажмите кнопку Установить.

    По завершению установки нажмите Далее.

    После появления окна с надписью «Установка SQL Server 2008 успешно завершена» нажмите Закрыть.

    А теперь лучше компьютер перезагрузить.

    Правила формирования имен объектов SQL сервера

    При задании имен создаваемых объектов серверов и баз данных, которые создаются на сервере, MS SQL задает ряд правил, пердставленных ниже.

    максимальная длина имени — 128 символов для SQL Server 7.0

    первым символом имени должна быть буква латинского алфавита или один из символов: @, _, #. Все остальные символы — буквы латинского алфавита, цифры или символы $, #, _.

    в идентификаторе не допускается использование внутренних пробелов.

    лучше не использовать в качестве имени зарезервированные слова SQL Server.

    символы @ и # имеют специальное значение, когда они применяются в качестве первого символа: @ означает переменную, а символ # объявляет именуемый объект временным объектом. Объект, который начинается с двух знаков ## — глобальный временный объект.

    Статьи на схожую тематику:

    Остались вопросы? Мы с радостью поможем Вам в их решении.

    Добавить комментарий