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

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

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

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

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

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

Операционная система семейства Windows (в моем примере используется )
Установленный Microsoft SQL Server 2008 R2 (об установке SQL Server можно прочитать )
Существующая база данный в SQL Server (о создании баз данных в SQL Server читайте )
Настроенная компонента 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) .

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

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

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

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

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

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

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

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

Общий вид

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

Перестроение индекса. Смысл задачи в удалении всех имеющихся индексов и установки новых. (грубо говоря инвентаризация и расстановка всего по порядку).
В качестве параметров:
- Выбор целевой базы (это будет почти во всех задачах, потому далее на этот параметр я не буду обращать внимание в пределах этой статьи).
- Объект, в котором мы выбираем «Таблицы и представления».
- Параметры свободного места – при малом объеме жесткого диска можно выбирать пункт «по умолчанию», однако я рекомендую использовать «Изменить долю свободного места на странице», рекомендуемое значение 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, но подробнее об этом я расскажу в другой статье.

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

microsoft.com/en-us/library/ms190

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

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

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

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

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

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

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

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

Итак в продолжении темы обслуживания баз 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 . Перетащим ее в план, и щелкнем на ней два раза. Мы видим окно, в которое впишем следующее:

DBCC FREEPROCCACHE