При администрировании крупных баз данных 1С на платформе MS SQL Server системные администраторы часто сталкиваются с ситуацией, когда регламентные операции по обслуживанию индексов выходят за рамки выделенного технологического окна. Рассмотрим ситуацию, когда база объемом более 80 Гб не обслуживалась в течение нескольких лет, и первая же попытка реорганизации индексов растянулась на сутки, создавая нагрузку на систему в рабочее время.
В этой статье мы подробно разберем, почему так происходит, можно ли прерывать процесс бэкапами и как оптимизировать обслуживание, чтобы оно не парализовало работу пользователей.
Проанализируем ситуацию: если база данных эксплуатировалась в течение 8 лет без регулярного перестроения или реорганизации индексов, степень их деградации становится критической. В таких случаях «первый раз» всегда сопряжен с колоссальными временными затратами. Разберем основные причины:
Full, объем лога может многократно превысить размер самой базы, что создает нагрузку на дисковую подсистему.Один из самых частых вопросов: «Могу ли я создавать резервные копии во время реорганизации?». Выясним технические нюансы этого процесса.
С технической точки зрения MS SQL Server позволяет выполнять BACKUP DATABASE одновременно с ALTER INDEX ... REORGANIZE. Реорганизация — это «онлайн» операция, которая не блокирует таблицу целиком и позволяет другим процессам (включая бэкап) обращаться к данным. Однако здесь есть важные «но»:
Во-первых, конфликт ресурсов. И обслуживание индексов, и резервное копирование — это операции, максимально нагружающие дисковую подсистему. Если запустить их одновременно, время выполнения обоих процессов увеличится кратно, а пользователи заметят существенные «тормоза» в 1С из-за огромных очередей к дискам.
Во-вторых, рост лога транзакций. Реорганизация индекса — это одна длинная транзакция или серия транзакций. Пока идет обслуживание, SQL Server не сможет полноценно усечь лог транзакций (даже если вы делаете бэкап лога каждые 10 минут). Это может привести к переполнению диска, где лежит файл .ldf.
Разберем ситуацию с ежедневным расписанием. Если ваше задание (Job) настроено на запуск ежедневно в 00:00, а предыдущее выполнение еще не завершилось, SQL Server Agent не запустит новую копию этого же задания. Он просто пропустит текущий цикл запуска. Это защищает систему от «наслаивания» тяжелых процессов друг на друга. Однако, как только текущее задание завершится (например, в 14:00), следующее запустится только в полночь по расписанию, если не задано иное.
Часто после успешного завершения задания администратор видит, что фрагментация некоторых индексов осталась на уровне 80–90%. Выясним причины этого явления, специфичные для 1С:
1. Маленькие таблицы. Это самая частая причина. В 1С сотни и тысячи служебных таблиц, которые занимают всего несколько страниц (менее 8 МБ). SQL Server не видит смысла в дефрагментации таких таблиц, так как они целиком помещаются в оперативную память при первом чтении. Для них высокая фрагментация — это норма, которую стоит игнорировать.
2. Хранилища значений (LOB-данные). В 1С активно используются поля типа ValueStorage, где хранятся файлы, картинки или длинные текстовые описания. Стандартная реорганизация может не затрагивать эти блоки данных. Для эффективной работы с ними требуется параметр LOB_COMPACTION = ON.
3. Коэффициент заполнения (Fill Factor). Посмотрим на настройки индексов. Если у вас установлен FILLFACTOR, например, 80%, SQL Server специально оставляет 20% свободного места на каждой странице для будущих записей. Некоторые инструменты анализа могут ошибочно интерпретировать это свободное место как фрагментацию.
Для баз 1С мы рекомендуем придерживаться следующей логики в зависимости от степени фрагментации:
ALTER INDEX ... REORGANIZE. Это менее ресурсоемко и не блокирует работу пользователей.ALTER INDEX ... REBUILD. Это полное пересоздание индекса.Важное замечание по Rebuild: В версии SQL Server Standard эта операция блокирует таблицу. Пользователи 1С не смогут проводить документы в этой таблице, пока индекс не перестроится. В версии Enterprise доступна опция ONLINE = ON, позволяющая делать перестроение без блокировок.
Проанализируем, как можно ускорить обслуживание базы в 80 Гб и более:
Шаг 1: Настройка параллелизма (MAXDOP). Проверьте параметр Max Degree of Parallelism. Если он установлен в 1, SQL Server использует только одно ядро процессора для обслуживания индекса. Для ускорения регламентных работ (особенно Rebuild) можно временно увеличивать этот параметр.
Шаг 2: Оптимизация TempDB. При перестроении индексов SQL Server использует TempDB для сортировки данных. Убедитесь, что файлы TempDB расположены на максимально быстрых дисках (NVMe/SSD). Это критически важно для производительности 1С.
Шаг 3: Порядок операций. Всегда сначала выполняйте обслуживание индексов, а только потом — обновление статистики. Дело в том, что REBUILD индекса автоматически обновляет статистику этого индекса с параметром FULLSCAN. Если вы сделаете наоборот, то потратите время на обновление статистики дважды.
Пример правильной последовательности действий в плане обслуживания:
-- 1. Перестроение сильно фрагментированных индексов (>30%)
ALTER INDEX ALL ON [Имя_Таблицы] REBUILD WITH (ONLINE = ON);
-- 2. Реорганизация слабо фрагментированных индексов (5-30%)
ALTER INDEX ALL ON [Имя_Таблицы] REORGANIZE;
-- 3. Обновление статистики для тех данных, которые не вошли в индексы
UPDATE STATISTICS [Имя_Таблицы] WITH FULLSCAN;
Ситуация, когда обслуживание базы после 8-летнего перерыва идет сутки — нормальна. Главное — не прерывать процесс и дождаться его завершения. В дальнейшем, при условии выполнения регламентов хотя бы раз в неделю, время обслуживания сократится с десятков часов до 30–60 минут. Помните, что для 1С критически важно поддерживать индексы в актуальном состоянии, так как это напрямую влияет на скорость проведения документов и формирование отчетов.