Сегодня рассмотрим один из вариантов обслуживания баз 1С в СУБД MS SQL.
Содержание:
1. Немного теории по планам обслуживания
2. Постановка задачи по созданию планов обслуживания
3. Создание плана обслуживания (Полная копия)
4. Создание плана обслуживания (Разностная копия)
5. Создание плана обслуживания (Резервная копия журналов транзакций)
6. Мониторинг планов обслуживания
1. Немного теории по планам обслуживания
Может многие со мой не согласятся, но для меня главной целью использования Планов обслуживания в MS SQL является создание резервных копий. Местные ITишники либо еще не делают резервные копии, либо уже делают, после печальных последствий отсутствия резервных копий. Да, не спорю, Планы обслуживания также нужны для оптимизации БД и выгрузки журналов транзакций, в последнем случаи, если не выполнять выгрузку журналов транзакций, у вас может вырасти база данных и занять все пространство на диске, 1С встанет колом и пользователи не смогут работать с базой, а вам придется выполнять шринк (Shrink) базы, это наверно самое страшное для ITишники после поломки базы и отсутствии резервных копий. Но об шринке (Shrink) поговорим в другой раз.
MS SQL Server поддерживает три модели восстановления:
1) Simple (Простая) — хранится только необходимый для жизни остаток журнала транзакций.
2) Full (Полная) — хранится весь журнал транзакций с момента последнего резервного копирования журнала транзакций.
3) Bulk logged (С неполным протоколированием) — часть операций записываются в очень компактном формате. В остальном идентична Full.
Модель восстановления базы можно посмотреть, в свойствах базы данных, на вкладке Параметры. Там же ее можно поменять. На практике я использую Full (Полная).
MS SQL поддерживает три типа формирования резервных копий:
1) Full (Полная копия)
2) Differential (Дифференциальная копия, Разностная копия)
3) Log (Резервная копия журналов транзакций)
Не путайте понятия: полная модель восстановления и полная резервная копия — разные вещи.
Рассмотрим подробно три типа формирования резервных копий.
1) Полная резервная копия
Позволяет восстановить состояние базы данных на некоторый момент времени. Состоит из копии файлов данных и журнала транзакций на момент завершения формирования резервной копии.
2) Разностная резервная копия
Хранит данных, изменившиеся с момента последней Полной резервной копии. При восстановлении нужно сначала восстановить Полную резервную копию в режиме NORECOVERY, потом можно применить любую из последующих Разностных копий. За счет этого можно значительно снизить объём дискового пространства для хранения резервной копии. Обратите внимание: без предыдущей Полной резервной копии Разностная копия бесполезна. Каждая последующая Разностная копия будет хранить все данные, входящие в предыдущую Разностную резервную копию, сделанную после предыдущей Полной копии. Поэтому каждая следующая Разностная копия больше предыдущих, пока снова не сделать Полную копию. Соответственно для восстановления на какой-то момент времени достаточно последней Полной резервной копии и последней Разностной копии. Промежуточные копии для восстановления не нужны.
3) Резервная копия журналов транзакций
Содержит копию журналов транзакций за некоторый период. Обычно с момента прошлой Резервной копии журналов транзакций до момента формирования текущей Резервной копии журналов транзакций. За счет этого Резервные копии журналов транзакций позволяют (с учетом Полной и Разностной копий) восстановить базу данных на любой момент времени. Резервная копия журналов транзакций высвобождает место в файле журнала транзакций, что позволяет ITишники избавиться от шринка базы данных.
Обратите внимание: набор Резервных копий журналов транзакций по сути бесполезен, если он не является непрерывной цепочкой, причем момент начала последнего успешного Полного или Разностного резервного копирования должен быть внутри периода этой цепочки.
2. Постановка задачи по созданию планов обслуживания
В организации N работают по шестидневке с 8:00 до 17:00. Обед с 12:00 до 13:00.
Имеется в MS SQL база данных с именем Moodle.
Что нужно сделать:
1) Проверить модель восстановления базы данных, должна быть Полная.
2) Создать план обслуживания, который будет создавать Полную резервную копию базы данных каждое воскресение в 17:00. Очищать хранилище от устаревших резервных копий старше 15 дней.
3) Создать план обслуживания, который будет создавать Разностную копию базы данных каждый день в 21:00 кроме воскресения.
4) Создать план обслуживания, который будет создавать Резервную копию журналов транзакций два раза в день, в 12:00 и в 17:00, кроме воскресения.
3. Создание плана обслуживания (Полная копия)
Запускаем SQL Server Management Studio, в Обозревателе объектов проходим по ветке Управление - Планы обслуживания.
Ниже на рисунке представлен результат настройки, который должен у нас получится, но все по порядку.
Размещаем задачу "Проверка целостности базы данных", двойным щелчком мыши открываем диалог настройки задачи, в первую очередь в свойстве Базы данных отмечаем нужную базу, а остальное настраиваем как показано на рисунке. При желании можно посмотреть T-SQL код полученной задачи.
Размещаем следующую задачу "Перестроение индекса" она у нас будет выполнятся только после успешно выполненной предыдущей задачи. Настраиваем как показано на рисунке, не забываем указать конкретную базу данных.
Для связи двух задач щелкните по первой задаче "Проверка целостности базы данных" у этой задачи появится стрелка, щелкните по ней и не отпуская соедините со второй задачей "Перестроение индекса". Для изменения значения условия выполнение следующей задачи, щелкните два раза по линии и в открывшемся диалоговом окне выполните необходимые настройки.
Содержание:
1. Немного теории по планам обслуживания
2. Постановка задачи по созданию планов обслуживания
3. Создание плана обслуживания (Полная копия)
4. Создание плана обслуживания (Разностная копия)
5. Создание плана обслуживания (Резервная копия журналов транзакций)
6. Мониторинг планов обслуживания
1. Немного теории по планам обслуживания
Может многие со мой не согласятся, но для меня главной целью использования Планов обслуживания в MS SQL является создание резервных копий. Местные ITишники либо еще не делают резервные копии, либо уже делают, после печальных последствий отсутствия резервных копий. Да, не спорю, Планы обслуживания также нужны для оптимизации БД и выгрузки журналов транзакций, в последнем случаи, если не выполнять выгрузку журналов транзакций, у вас может вырасти база данных и занять все пространство на диске, 1С встанет колом и пользователи не смогут работать с базой, а вам придется выполнять шринк (Shrink) базы, это наверно самое страшное для ITишники после поломки базы и отсутствии резервных копий. Но об шринке (Shrink) поговорим в другой раз.
MS SQL Server поддерживает три модели восстановления:
1) Simple (Простая) — хранится только необходимый для жизни остаток журнала транзакций.
2) Full (Полная) — хранится весь журнал транзакций с момента последнего резервного копирования журнала транзакций.
3) Bulk logged (С неполным протоколированием) — часть операций записываются в очень компактном формате. В остальном идентична Full.
Модель восстановления базы можно посмотреть, в свойствах базы данных, на вкладке Параметры. Там же ее можно поменять. На практике я использую Full (Полная).
MS SQL поддерживает три типа формирования резервных копий:
1) Full (Полная копия)
2) Differential (Дифференциальная копия, Разностная копия)
3) Log (Резервная копия журналов транзакций)
Не путайте понятия: полная модель восстановления и полная резервная копия — разные вещи.
Рассмотрим подробно три типа формирования резервных копий.
1) Полная резервная копия
Позволяет восстановить состояние базы данных на некоторый момент времени. Состоит из копии файлов данных и журнала транзакций на момент завершения формирования резервной копии.
2) Разностная резервная копия
Хранит данных, изменившиеся с момента последней Полной резервной копии. При восстановлении нужно сначала восстановить Полную резервную копию в режиме NORECOVERY, потом можно применить любую из последующих Разностных копий. За счет этого можно значительно снизить объём дискового пространства для хранения резервной копии. Обратите внимание: без предыдущей Полной резервной копии Разностная копия бесполезна. Каждая последующая Разностная копия будет хранить все данные, входящие в предыдущую Разностную резервную копию, сделанную после предыдущей Полной копии. Поэтому каждая следующая Разностная копия больше предыдущих, пока снова не сделать Полную копию. Соответственно для восстановления на какой-то момент времени достаточно последней Полной резервной копии и последней Разностной копии. Промежуточные копии для восстановления не нужны.
3) Резервная копия журналов транзакций
Содержит копию журналов транзакций за некоторый период. Обычно с момента прошлой Резервной копии журналов транзакций до момента формирования текущей Резервной копии журналов транзакций. За счет этого Резервные копии журналов транзакций позволяют (с учетом Полной и Разностной копий) восстановить базу данных на любой момент времени. Резервная копия журналов транзакций высвобождает место в файле журнала транзакций, что позволяет ITишники избавиться от шринка базы данных.
Обратите внимание: набор Резервных копий журналов транзакций по сути бесполезен, если он не является непрерывной цепочкой, причем момент начала последнего успешного Полного или Разностного резервного копирования должен быть внутри периода этой цепочки.
2. Постановка задачи по созданию планов обслуживания
В организации N работают по шестидневке с 8:00 до 17:00. Обед с 12:00 до 13:00.
Имеется в MS SQL база данных с именем Moodle.
Что нужно сделать:
1) Проверить модель восстановления базы данных, должна быть Полная.
2) Создать план обслуживания, который будет создавать Полную резервную копию базы данных каждое воскресение в 17:00. Очищать хранилище от устаревших резервных копий старше 15 дней.
3) Создать план обслуживания, который будет создавать Разностную копию базы данных каждый день в 21:00 кроме воскресения.
4) Создать план обслуживания, который будет создавать Резервную копию журналов транзакций два раза в день, в 12:00 и в 17:00, кроме воскресения.
3. Создание плана обслуживания (Полная копия)
Запускаем SQL Server Management Studio, в Обозревателе объектов проходим по ветке Управление - Планы обслуживания.
Правой кнопкой по пункту Планы обслуживания и в контекстном меню выбираем Создать план обслуживания... Указываем имя, к примеру: Moodle. В открывшемся конструкторе будем создавать вложенные планы обслуживания. щелкните два раза по строке ВложенныйПлан _1
Задайте Имя, Описание и обязательно настройте Расписание выполнения вложенного плана обслуживания: еженедельно в воскресение 17:00:00
Используя Панель элементов создадим первый вложенный план. Достаточно нужный элемент в панели ухватить, перенести на рабочую область и там бросить. Для открытия мастера настройки элемента достаточно два раза щелкнуть по элементу.Ниже на рисунке представлен результат настройки, который должен у нас получится, но все по порядку.
Размещаем задачу "Проверка целостности базы данных", двойным щелчком мыши открываем диалог настройки задачи, в первую очередь в свойстве Базы данных отмечаем нужную базу, а остальное настраиваем как показано на рисунке. При желании можно посмотреть T-SQL код полученной задачи.
Размещаем следующую задачу "Перестроение индекса" она у нас будет выполнятся только после успешно выполненной предыдущей задачи. Настраиваем как показано на рисунке, не забываем указать конкретную базу данных.
Для связи двух задач щелкните по первой задаче "Проверка целостности базы данных" у этой задачи появится стрелка, щелкните по ней и не отпуская соедините со второй задачей "Перестроение индекса". Для изменения значения условия выполнение следующей задачи, щелкните два раза по линии и в открывшемся диалоговом окне выполните необходимые настройки.
Размещаем задачу "Обновление статистики" которая будет выполнятся после завершения предыдущей. Настраиваем эту задачу как на рисунке, не забываем выбрать базу данных.
Размещаем задачу "Выполнение инструкции T-SQL" с кодом:
DECLARE @intDBID INTEGER SET @intDBID = (SELECT dbid FROM master.dbo.sysdatabases WHERE name = 'Moodle')
DBCC FLUSHPROCINDB (@intDBID)
Инструкция DBCC FREEPROCCACHE используется для аккуратной очистки кэша планов. Освобождение кэша планов приводит, например, к тому, что хранимая процедура повторно компилируется, а не используется из кэша.
При настройке для своей базы не забываем изменить имя БД Moodle.
Размещаем следующую задачу "Резервное копирование базы данных" она у нас будет выполнятся полную резервную копию базы данных. Размещать резервные копии желательно на СХД, если нет, то на другом физическом диске, но ни в коем случае на том же диске где сама база данных, иначе теряется весь смысл резервных копий. Настраиваем как показано на рисунке, не забываем указать конкретную базу данных.
Размещаем следующую задачу "Очистка журнала" она у нас будет выполнятся очистку журналов. Настраиваем как показано на рисунке.
Размещаем следующую задачу "Очистка после обслуживания" она у нас будет выполнятся удаление старых файлов резервных копий, так как свойстве Расширение файла указана маска *.*, то удаляются будут все файлы, и полной резервной копии, и разностной, и журнала транзакций. Настраиваем как показано на рисунке.
Обратите внимание, две последние задачи выполняются после выполнения задачи "Резервное копирование базы данных" и самое главное, задачу "Очистка после обслуживания" нужно выполнять только после успешно выполненной задачи "Резервное копирование базы данных". Что бы не получилось, что у вас уже который раз не создаются резервные копии, а вы задачей "Очистка после обслуживания" удаляете последние актуальные копии.
4. Создание плана обслуживания (Разностная копия)
Добавим вложенный план обслуживания, на рисунке ниже красной рамкой выделена данная кнопка и показан результат схемы обслуживания, который должен получится, но все по порядку.
Заполним поля свойств и настроим расписание как показано на рисунке.
Размещаем две задачи "Проверка целостности базы данных" и "Резервное копирование базы данных", обратите внимание последняя задача выполняется только после успешного завершения предыдущей. Иначе какой смысл делать резервную копию если она не корректна.
На рисунке представлена настройка задачи "Проверка целостности базы данных".
На рисунках представлены настройки задачи "Резервное копирование базы данных". Обратите внимание на Тип резервной копии, должен стаять Разностное. И не забудьте указать конкретную базу данных.
5. Создание плана обслуживания (Резервная копия журналов транзакций)
Добавим два вложенных плана обслуживания, один настроим на 12:00 второй на 17:00.
На рисунке представлен результат плана обслуживания на 12:00, на 17:00 отличатся ничем не будет, только временем выполнения.
Разместим одну задачу "Резервное копирование базы данных". Обратите внимание на Тип резервной копии, должен стаять Журнал тарнзакций. И не забудьте указать конкретную базу данных.
6. Мониторинг планов обслуживания
После создания всех Планов обслуживания они появятся в ветке Агент SQL Server.
Откройте Мониторинг активности заданий, в этом мониторинге можно увидеть какие задачи, когда выполнялись, когда следующее выполнение и успешно ли они выполнялись.
Для запуска определенного плана, достаточно в контекстном меню выбрать пункт Запустить задание на шаге...
P/S
Сегодня рассмотрели минимальные азы создания планов обслуживания в MS SQL по созданию трех типов резервных копий баз данных: Full (Полная копия), Differential (Дифференциальная копия, Разностная копия) и Log (Резервная копия журналов транзакций).
Спасибо большое!!!
ОтветитьУдалитьХорошая статья. Спасибо.
ОтветитьУдалить"Иначе какой смысл делать резервную копию если она не корректна."
Тут стоит немного подправить текст.
Спасибо!!!
Удалитьнемного непонятно с T-SQL инструкцией.
ОтветитьУдалитьпо тексту:
Размещаем задачу "Выполнение инструкции T-SQL" с кодом:
DECLARE @intDBID INTEGER SET @intDBID = (SELECT dbid FROM master.dbo.sysdatabases WHERE name = 'Moodle')
DBCC FLUSHPROCINDB (@intDBID)
Инструкция DBCC FREEPROCCACHE используется для аккуратной очистки кэша планов. Освобождение кэша планов приводит, например, к тому, что хранимая процедура повторно компилируется, а не используется из кэша.
----------
т.е. сначала идет код, затем пояснение по инструкции "DBCC FREEPROCCACHE", но при этом в коде она не используется.
где-то ошибка? Если просто написать вместо того большого кода вот это "DBCC FREEPROCCACHE" он не сработает?
DBCC FREEPROCCACHE очищает весь кэш сервера, по всем базам.
УдалитьКод выше позволяет очистить только по базе "Moodle"
Отличная статья , Спасибо, скажите на некоторых ресурсах после обновления статистики делают " SELECT * FROM sys.dm_db_index_physical_stats " как я понял это дефрагментация индексов, нужен он вообще ?
ОтветитьУдалитьНужно анализировать процент фрагментации в столбце avg_fragmentation_in_percent если он превышает 25% то нужно выполнять дефрагментацию этого индекса. Официальный источник https://its.1c.ru/db/metod8dev/content/1794/hdoc
УдалитьЗдравствуйте! Спасибо за статью. А как можно делать разностные копии в тот же файл что и последняя полная копия через план обслуживания?
ОтветитьУдалить