← На главную

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

Понимание модели восстановления Simple и работа с логами

Прежде всего, проанализируем, как ведет себя журнал транзакций в режиме Simple. В отличие от модели Full, здесь не поддерживается цепочка логов для восстановления на произвольный момент времени. Журнал транзакций очищается автоматически при достижении контрольной точки (checkpoint).

Выясним, нужно ли включать в план обслуживания операцию «Очистка журнала». Ответ однозначный: бэкап журнала транзакций (Transaction Log Backup) в режиме Simple невозможен и не нужен. Однако это не означает, что файл .ldf перестанет расти. Рассмотрим ситуации, когда лог все равно может увеличиться:

• Длинные транзакции: Если в 1С выполняется тяжелая операция (например, закрытие месяца), лог будет расти до завершения всей транзакции.
• Обслуживание индексов: Перестроение индексов (Rebuild) — это массовая операция, которая требует значительного места в журнале.

Проанализируем вопрос ограничения размера лога. Не рекомендуется устанавливать жесткий лимит на размер файла .ldf, так как при нехватке места регламентные задания или операции в 1С завершатся с ошибкой. Вместо этого лучше обеспечить наличие свободного места на диске.

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

Рассмотрим этап, который часто упускают из виду — Check Database Integrity (команда DBCC CHECKDB). Это критически важная операция, которую необходимо выполнять ПЕРЕД созданием резервной копии. Разберем причину: если в базе данных есть логические или физические повреждения страниц, создание бэкапа просто «законсервирует» эту проблему. В режиме Simple бэкап — ваша единственная точка восстановления, поэтому мы должны быть уверены в его валидности.

Обслуживание индексов: Перестроение или Реорганизация?

Работа с индексами напрямую влияет на производительность 1С. В теме форума разгорелась дискуссия: что лучше? Посмотрим на общепринятые стандарты, которые актуальны для 1С:

1. Реорганизация индекса (Reorganize): Применяется при фрагментации от 5% до 30%. Это легкая операция, которая не блокирует таблицы и может выполняться даже во время работы пользователей. Важно помнить, что реорганизация не обновляет статистику.
2. Перестроение индекса (Rebuild): Применяется при фрагментации более 30%. Это фактически создание индекса заново. Если у вас версия SQL Server Standard, таблица будет полностью заблокирована. В версии Enterprise можно использовать опцию ONLINE = ON.

Проанализируем нюанс с 1С: даже в версии Enterprise не все таблицы можно перестроить онлайн. Если в таблице есть поля старых типов данных, таких как IMAGE или NTEXT (что встречается в старых версиях платформ или определенных конфигурациях), SQL Server выполнит блокировку. Поэтому планировать Rebuild лучше на периоды минимальной нагрузки.

Обновление статистики: нужно ли оно после индексов?

Выясним связь между индексами и статистикой. В сообщениях форума справедливо отмечено: полное перестроение индекса (Rebuild) автоматически обновляет статистику с параметром FULLSCAN. В этом случае дополнительное задание «Обновление статистики» сразу после перестроения будет избыточным и бесполезным.

Однако статистика требуется и для тех полей, которые не входят в индексы. Поэтому правильная стратегия выглядит так:

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

Использование профессиональных скриптов

Вместо стандартных планов обслуживания SQL Management Studio (SSMS) многие эксперты рекомендуют использовать бесплатные скрипты Олы Халленгрена. Разберем, почему это эффективно:

• Они автоматически определяют уровень фрагментации и выбирают между Rebuild и Reorganize.
• Они корректно обрабатывают статистику.
• Они позволяют сократить время обслуживания. Как было замечено в обсуждении, переход на умные скрипты может сократить время регламентов с 5 часов до 2.

Резервное копирование в режиме Simple

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

1. Full Backup (Полный): Раз в сутки (обычно ночью).
2. Differential Backup (Разностный): Несколько раз в день (например, каждые 3–4 часа). Это позволит восстановить данные на момент разностного бэкапа, если база «упадет» в середине дня.

Дополнительные настройки для производительности

Для стабильной работы 1С в связке с SQL Server обратим внимание на два важных параметра:

Параметр MAXDOP: При перестроении индексов SQL Server может попытаться задействовать все ядра процессора. Это приведет к тому, что 1С начнет «тормозить» у всех пользователей. Рекомендуется ограничивать Max Degree of Parallelism для регламентных заданий значением 1–4.

Очистка истории: Не забывайте добавлять в план задачу Maintenance Cleanup Task и History Cleanup. Первая удаляет старые файлы бэкапов с диска, вторая — очищает историю выполнения заданий в системной базе msdb, предотвращая ее разрастание.

Подведем итог: идеальный план обслуживания для базы 1С в режиме Simple должен выглядеть так: Проверка целостности -> Обслуживание индексов (умное) -> Обновление статистики (где не было Rebuild) -> Полный бэкап -> Очистка старых файлов и истории.