Настройка плана обслуживания sql 2016 для 1с
После очередной просьбы рассказать как составить план обслуживания sql-баз используемый , решил поделиться опытом со всеми сразу.
Зачем это надо — если в sql не обслуживать базы данных, то его смысл теряется вовсе. Основной инструмент — индексы и их надо держать в актуальном состоянии. Каких-то догматов я не встретил не в практике, не в нете, не на курсах в самой 1С, а потому делюсь своим опытом.
- Сервер SQL хорошо «питается», т.е. объем ОЗУ предоставляемой для работы SQL сервера выбирать из расчёта 70% от размера всех mdf файлов баз данных.
- Процессор не загружен более чем на 50% в течении 90% времени.
- Имеется достаточное место на дисках (в частности для сортировки используется база temp.db, 1С ее использует вообще для всей своей жизнедеятельности, потому стоит заранее озаботиться местом на диске с этой базой).
- Режим восстановления базы данных — «Простой». (Эмпирически выяснено, что большой ldf файл тормозит 1с-ку, а возможность восстановления по лог-файлу весьма сомнительна).
- При использовании Standard редакции SQL, при полном перестроении индекса, все пользователи будут отключены от базы, потому стоит это учитывать при решении проведения Weekly плана обслуживания (план будет описан ниже).
- Стоит учитывать, что сервер 1С тоже потребляет память, особенно если используются тонкие клиенты или веб-службы.
- Самому SQL лучше ограничить в параметрах сервера максимальный объем ОЗУ, дабы по достижению критической массы, он заранее начинал очищать ненужные данные из ОЗУ. Да и чтоб разрастаясь не вгонять весь сервер в ступор.
Weekly
- Перестроение индекса. Смысл задачи в удалении всех имеющихся индексов и установки новых. (грубо говоря инвентаризация и расстановка всего по порядку).
В качестве параметров:- Выбор целевой базы (это будет почти во всех задачах, потому далее на этот параметр я не буду обращать внимание в пределах этой статьи).
- Объект, в котором мы выбираем «Таблицы и представления».
- Параметры свободного места – при малом объеме жесткого диска можно выбирать пункт «по умолчанию», однако я рекомендую использовать «Изменить долю свободного места на странице», рекомендуемое значение 20%. Это позволит оставить запас свободных страниц, и позволит дольше держать индексы в актуальном состоянии. ВНИМАНИЕ: Увеличивает размер базы данных.
- Отсортировать результаты в tempdb. Думаю пояснять не требуется, однако предупредить хочу, в это время tempdb, будет очень сильно разрастаться, хоть и сортировка в ней и призвана ускорить процесс, будьте осторожны, имейте запас пространства.
- Сохранять индекс в режиме «в сети» — фишка доступная для enterprise версии SQL. Позволяет делать переиндексацию без отключения клиентов.
- Объект. Все те же таблицы и представления, что и для перестроения индекса.
- Обновить. Тут обновляем всю статистику.
- Тип просмотра – Полный просмотр.
- SQL не умеет чистить контейнер свой, потому если добавлять резервные копии в файл (оно же обзывается «Устройство резервного копирования»), в итоге забьете все свободное место.
- SQL помнит о своих резервных копиях, потому сделав ручками бэкап, единоразовый (например, отнести базу в другое место, или чтоб развернуть для теста в еще одну базу из бэкапа), следующий «разностный» будет отсчитываться от него. Дабы предотвратить это, требуется ставить галочку «Только резервное копирование». В задаче резервного копирования такого пункта нет. Вообще в недельном плане рекомендую все же использовать полный тип резервной копии.
- И хорошо бы проверять копию, пусть спиться спокойнее.
- Сжатие, в общем-то, использовать можно, но будьте аккуратны, разностные тогда надо тоже сжимать.
- Журнал резервного копирования и восстановления.
- Журнал заданий агента SQL Server.
- Журнал плана обслуживания.
Daily
Так же можно использовать разностное резервное копирование.
На этом все. Повторяюсь, догматов в этом моменте я не видел, этот вариант был разработан и протестирован мной. Актуально для баз размером от 6 до 100 ГБ.
Сегодня рассмотрим один из вариантов обслуживания баз 1С в СУБД MS SQL.
Содержание:
1. Немного теории по планам обслуживания
2. Постановка задачи по созданию планов обслуживания
3. Создание плана обслуживания (Полная копия)
4. Создание плана обслуживания (Разностная копия)
5. Создание плана обслуживания (Резервная копия журналов транзакций)
6. Мониторинг планов обслуживания
1. Немного теории по планам обслуживания
Может многие со мой не согласятся, но для меня главной целью использования Планов обслуживания в MS SQL является создание резервных копий. Местные ITишники либо еще не делают резервные копии, либо уже делают, после печальных последствий отсутствия резервных копий. Да, не спорю, Планы обслуживания также нужны для оптимизации БД и выгрузки журналов транзакций, в последнем случаи, если не выполнять выгрузку журналов транзакций, у вас может вырасти база данных и занять все пространство на диске, 1С встанет колом и пользователи не смогут работать с базой, а вам придется выполнять шринк (Shrink) базы, это наверно самое страшное для ITишники после поломки базы и отсутствии резервных копий. Но об шринке (Shrink) поговорим в другой раз.
Модель восстановления базы можно посмотреть, в свойствах базы данных, на вкладке Параметры. Там же ее можно поменять. На практике я использую Full (Полная).
Рассмотрим подробно три типа формирования резервных копий.
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С Предприятия, размещенных в MS SQL.
Настройка плана обслуживания баз данных MS SQL Server выполняется через программу Microsoft SQL Management Studio. Рассмотрим задачи, которые мы будем выполнять в рамках регулярного обслуживания баз данных:
-
(раз в неделю, в воскресенье в 2:00); (раз в день, с понедельника по субботу в 2:00); (раз в день); (раз в день в 4:00); (раз в день).
В чем отличие полного бэкапа от разностного?
Полное резервное копирование сохраняет всю базу данных целиком.
Разностное резервное копирование сохраняет все изменения созданные в базе данных с момента последнего полного бэкапа.
Такой подход к резервному копированию позваляет экономить свободное пространство на носителях информации.
Создание полного бэкапа базы.
В обозревателе объектов переходим к пункту "Управление \ Планы обслуживания". В контекстном меню выбираем "Создать план обслуживания".
В этом основном плане обслуживания будем создавать вложенные планы полного бэкапа, промежуточного (разностного) бэкапа, перестроение индекса и обновление статистики.
В созданном плане нажимаем кнопку "Добавление вложенного плана"
Вводим название "Полный бэкап" и описание. Задаем расписание для выполнения задания: Раз в неделю в воскресенье в 2:00.
Добавляем в созданный план задание. Для этого с панели элементов перетаскиваем в поле заданий вложенного плана элемент с названием Задача "Резервное копирование базы данных".
Открываем задание на редактирование: правой клавишей мыши по заданию, выбираем пункт "Изменить".
- Тип резервной копии: Полное;
- Базы данных: если выбрать "Все пользовательские базы данных", то будет выполняться бэкап всех созданных вами баз данных, но есть возможность указать на конкретные базы;
- Создать файл резервной копии для каждой базы данных: отмечаем пункт "Создавать вложенный каталог для каждой базы данных", чтобы удобнее было ориентироваться в бэкапах и указываем путь как папке, в которой будут храниться резервные копии;
- Отмечаем пункт "Проверять целостнойсть резервной копии";
- Устанавливаем параметр "Сжимать резервные копии".
Создание разностного бэкапа.
Создание плана на выполнение разностного бэкапа выполняется аналогично полному бэкапу.
Отметим некоторые отличия в настройке:
- Расписание выполнения заданий: с понедельника по субботу в 2:00;
- Тип резервной копии выбираем "Разностное"
Очистка устаревших бэкапов.
Для очистки устаревших бэкапов баз 1С Предприятия в MS SQL выбираем на панели элементов плана обслуживания Задачу "Очистка после обслуживания".
В моем случае разностный и полный бэкап хранятся в одной папке. Поэтому я добавляю только одно такое задание во вложенный план для разностного бэкапа. Если вы резервные копии будете хранить отдельно, то лучше создать отдельное задание в плане каждого бэкапа.
Перетаскиваем задачу с Панели элементов в план и задаем такие настройки:
- Удалить файлы следующего типа: Файлы резервных копий;
- Удалить из папки файлы с определенным расширением: указываем папку хранения бэкапов баз 1С;
- Включить вложенные папки первого уровня: отмечаем галочкой, потому-что у нас для бэкапов баз создаются отдельные папки
- Удалить файлы на основе возраста во время выполнения задачи: здесь все ограничивается лишь вашими потребностями и объемом жесткого диска, а мне достаточно 4 недель.
Чтобы в текущем плане после выполнения первого задания начало выполнятся следующее, их необходимо соединить между собой стрелками. Для этого выделяем первое задание и ведем стрелку от него к следующему.
Через стрелки можно задавать условие, при котором будет выполнять следующее задание: ошибка, успешное завершение, выполнение. Изменить условие можно щелкнув правой клавишей мыши по стрелке.
По умолчанию стрелка зеленого цвета. Это значит, что следующее задание будет выполняться только при успешном завершении первого. Это условие подходит для моего случая.
Переходим к очень важному и ответственному пункту: Перестроение индекса и обновление статистики.
Дефрагментация индекса (реорганизация или перестроение).
В процессе работы базы данных 1С Предприятия, в результате постоянной записи и удаления данных, образуются пустые (фрагментированные) области. По этой причине может увеличиваться бесполезный объем БД и замедляться скорость взаимодействия с ней.
Для устранения фрагментированных областей баз данных в MS SQL существует возможность проведения Реорганизации индекса и Перестроение индекса.
В чем разница между реорганизацией и перестроением?
Перестроение индекса означает, что фрагментация будет устранена путем удаления и пересоздания индексов.
При Реорганизации индекска происходит перестроение индексов в соответствии с логическим порядком. Этот способ наименее ресурсозатратный и является более предпочтительным для регулярного обслуживания баз данных.
В каких случаях требуется реорганизация индекса?
- Уровень фрагментации от 5% до 30%, то проводим реорганизацию.
- Фрагментация свыше 30% необходимо проводить перестроение индекса
Под выполнение этих задач очень подходит инструкция Transact-SQL со следующим содержимым:
Создаем вложенный план с названием "Дефрагментация индекса и обновление статистики" с расписанием раз в день в 4:00 и перетаскиваем в него из Панели элементов Задачу "Выполнение инструкции T-SQL".
Вставляем в задачу приведенную выше инструкцию T-SQL.
Обновление статистики.
Обновление статистики в базах данных MS SQL, как и дефрагментация индекса, имеет большое значение для повышения производительности работы SQL сервера. Благодаря обновлению статистики SQL Server способен более эффективно выполнять планы запроса.
Выбираем на панели элементов Задача "Обновление статистики" и добавляем ее во вложенный план "Дефрагментация индекса и обновление статистики".
- Базы данных: все пользовательские базы данных;
- Обновить: вся собранная статистика;
- Тип просмотра: полный просмотр.
При помощи стрелки связываем условием выполнение задачи по обновлению индекса с задачей по дефрагментации. Таким образом в случае успешного выполнения дефрагментации будет проведено обновление статистики.
В целом настройка MS SQL Server для работы с 1С предприятия не сильно отличается от его обычной настройки, но все же есть некоторые нюансы выявленные опытным путем.
Рассмотрим наиболее важные моменты в установке и последующей настройке сервера и баз данных, чтобы оптимизировать работу 1С.
Содержание:
Установка MS SQL Server
Не будем рассматривать все шаги установки и затронем только те моменты, которые требуют особого внимания.
Выбор и настройка компонентов
Для работы MS SQL Server c 1С Предприятие достаточно выбрать следующий набор компонент:
- Службы компонента Dtabase Engine
- Средства связи клиентских средств
- Средства управления - основные
- Средства управления - полный набор (полный набор нам будет необходим для создания плана обслуживания)
Важно! Каталог общих компонентов лучше указывать на отдельном диске (отдельно от операционной системы). Это повысит скорость работы и отказоустойчивость.
Конфигурация сервера
Для запуска служб Агент SQL Server и SQL Database Engine указываем учетную запись. Можно создать отдельнную учетную запись с правами администратора, либо указать учетную запись Администратор. Однако стоит помнить - если Вы решите когда-нибудь сменить пароль для учетной записи, которую здесь указали, то и служба перестанет запускаться. Поэтому используйте учетную запись в которой не планируете менять пароль.
Настройке компонента Databse Engine
Указываем смешанный режим и задаем пароль для sa - системной учетной записи SQL Server.
Добавляем учетные записи компьютера или домена, которые смогут администрировать SQL.
Далее все настройки можно оставить по-умолчанию.
Настраиваем брэндмауэр для работы mssql и 1С Серверa
Создаем правила разрешающее входящие подключения на порт 1433 для MS SQL и 1541-1560 для 1С Сервера
Создаем правило для программы. Путь до программы будет выглядеть примерно так
C:\Program Files\Microsoft SQL Server\MSSQL13.<InstanceName>\MSSQL\Binn\sqlservr.exe
Настройка свойств сервера Ms SQL для работы с 1С
Запускаем Microsoft SQL Server Management Studio и подключаемся к серверу.
Переходим к пункту Процессор. Максимальное число рабочих потоков так же лучше установить вручную и задать значение 2048 так как при значении 0 число потоков может не превышать 255. Включаем параметр Поддерживать приоритет SQL.
Конечно эти советы по настройке свойств сервера не панацея и не во всех условиях они будут одинаково хороши, но для большинства случаев думаю вполне подойдет.
Настройка рабочей базы 1С Предприятия
Открываем свойства настраиваемой базы данных.
Теперь самое главное определится с моделью восстановления базы данных. Они настраиваются в нукте параметры. Рассмотрим две основные модели восстановления.
1. Простая. Ее нужно использовать в том случае, когда вы планируете делать бэкап раз в день и для вас не имеет значения возможность восстановления с точностью до определенного момента. Это может быть 1С Бухгалтерия или ЗУП где нет большого количества ежедневных транзакций. Делаете один бэкап каждую ночь и спите спокойно. Никаких сложностей.
2. Полная. Такую модель лучше всего использовать для бэкапа баз с большим количеством внутридневных транзакций, например продажи в 1С Розница. При такой модели у вас будут сохранятся все транзакции в журналах и будет возможность восстановления базы до любого момента времени. Но в этом случае придется повозится с настройками журналов транзакций.
Когда мы определились с моделью восстановления можно перейти к пункту [Файлы]
Для файла [Данные строк] размер авторасширения выставляем 200МБ. По-умолчанию выставлен 1МБ и это мало. Если у вас много транзакций по 1С, тогда SQL будет вынужден постоянно выполнять авторасширение и это будет тормозить его работу.
Настройку типа файла [Журнал] можно пропустить если используется простая модель восстановления.
Если используется полная то необходимо скорректировать настройки.Авторасширение установим 50МБ. Стоит обратить внимание на ограничение авторасширения и его лучше изменить т.к. значение по-умолчанию больше 2Тб. При большом количестве транзакций, например розничные продажи в 1С Розница, журнал транзакций будет расти очень быстро и вскоре у вас закончится свободное место на накопителе. Поэтому ограничение лучше установить на 10ГБ. Но это всего-лишь рекомендация, потому-что все индивидуально и зависит от количества транзакций.
При установке ограничения стоит помнить, что при достижении крайнего значения вас ждет ошибка: "журнал транзакций для базы данных заполнен" и 1С не будет запускаться. Чтобы журнал транзакций своевременно очищался необходимо настроить его бэкап в плане обслуживания базы данных. О том как создать план обслуживания базы данных читайте здесь.
Но очистка журнала транзакций не уменьшает размер самого файла, а только освобождает в нем свободное место для новых записей путем удаления неактивных завершенных транзакций.
Если же журнал переполнился, то его придется почистить вручную чтобы база заработала. Как это сделать читайте в этой статье.
После очередной просьбы рассказать как составить план обслуживания sql-баз используемый , решил поделиться опытом со всеми сразу.
Зачем это надо — если в sql не обслуживать базы данных, то его смысл теряется вовсе. Основной инструмент — индексы и их надо держать в актуальном состоянии. Каких-то догматов я не встретил не в практике, не в нете, не на курсах в самой 1С, а потому делюсь своим опытом.
- Сервер SQL хорошо «питается», т.е. объем ОЗУ предоставляемой для работы SQL сервера выбирать из расчёта 70% от размера всех mdf файлов баз данных.
- Процессор не загружен более чем на 50% в течении 90% времени.
- Имеется достаточное место на дисках (в частности для сортировки используется база temp.db, 1С ее использует вообще для всей своей жизнедеятельности, потому стоит заранее озаботиться местом на диске с этой базой).
- Режим восстановления базы данных — «Простой». (Эмпирически выяснено, что большой ldf файл тормозит 1с-ку, а возможность восстановления по лог-файлу весьма сомнительна).
- При использовании Standard редакции SQL, при полном перестроении индекса, все пользователи будут отключены от базы, потому стоит это учитывать при решении проведения Weekly плана обслуживания (план будет описан ниже).
- Стоит учитывать, что сервер 1С тоже потребляет память, особенно если используются тонкие клиенты или веб-службы.
- Самому SQL лучше ограничить в параметрах сервера максимальный объем ОЗУ, дабы по достижению критической массы, он заранее начинал очищать ненужные данные из ОЗУ. Да и чтоб разрастаясь не вгонять весь сервер в ступор.
Weekly
- Перестроение индекса. Смысл задачи в удалении всех имеющихся индексов и установки новых. (грубо говоря инвентаризация и расстановка всего по порядку).
В качестве параметров:- Выбор целевой базы (это будет почти во всех задачах, потому далее на этот параметр я не буду обращать внимание в пределах этой статьи).
- Объект, в котором мы выбираем «Таблицы и представления».
- Параметры свободного места – при малом объеме жесткого диска можно выбирать пункт «по умолчанию», однако я рекомендую использовать «Изменить долю свободного места на странице», рекомендуемое значение 20%. Это позволит оставить запас свободных страниц, и позволит дольше держать индексы в актуальном состоянии. ВНИМАНИЕ: Увеличивает размер базы данных.
- Отсортировать результаты в tempdb. Думаю пояснять не требуется, однако предупредить хочу, в это время tempdb, будет очень сильно разрастаться, хоть и сортировка в ней и призвана ускорить процесс, будьте осторожны, имейте запас пространства.
- Сохранять индекс в режиме «в сети» — фишка доступная для enterprise версии SQL. Позволяет делать переиндексацию без отключения клиентов.
- Объект. Все те же таблицы и представления, что и для перестроения индекса.
- Обновить. Тут обновляем всю статистику.
- Тип просмотра – Полный просмотр.
- SQL не умеет чистить контейнер свой, потому если добавлять резервные копии в файл (оно же обзывается «Устройство резервного копирования»), в итоге забьете все свободное место.
- SQL помнит о своих резервных копиях, потому сделав ручками бэкап, единоразовый (например, отнести базу в другое место, или чтоб развернуть для теста в еще одну базу из бэкапа), следующий «разностный» будет отсчитываться от него. Дабы предотвратить это, требуется ставить галочку «Только резервное копирование». В задаче резервного копирования такого пункта нет. Вообще в недельном плане рекомендую все же использовать полный тип резервной копии.
- И хорошо бы проверять копию, пусть спиться спокойнее.
- Сжатие, в общем-то, использовать можно, но будьте аккуратны, разностные тогда надо тоже сжимать.
- Журнал резервного копирования и восстановления.
- Журнал заданий агента SQL Server.
- Журнал плана обслуживания.
Daily
Так же можно использовать разностное резервное копирование.
На этом все. Повторяюсь, догматов в этом моменте я не видел, этот вариант был разработан и протестирован мной. Актуально для баз размером от 6 до 100 ГБ.
Читайте также: