← На главную

При работе с крупными базами данных 1С:Предприятия, особенно в конфигурациях типа 1С:Розница, часто возникает необходимость внесения изменений в структуру объектов, таких как регистры сведений. Эти изменения, будь то удаление неиспользуемых ссылочных ресурсов, изменение длины строковых полей или добавление новых реквизитов, запускают процесс реструктуризации базы данных. Длительность этого процесса является критически важным вопросом, поскольку он может занимать значительное время, влияя на доступность системы. Давайте рассмотрим, от чего зависит время реструктуризации и какие существуют методы для его сокращения.

Оценка времени реструктуризации базы данных

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

Мы выясним, какие ключевые аспекты влияют на скорость реструктуризации:

1. Количество записей в изменяемом объекте: Мы проанализируем, что размер базы данных в гигабайтах (ГБ) менее важен, чем количество записей в конкретном регистре или таблице, которая подвергается изменениям. Например, 100 000 записей в регистре могут обрабатываться несколько часов при использовании старого механизма реструктуризации.
2. Тип вносимых изменений: Мы рассмотрим, что удаление реквизита или добавление нового обычно происходит быстрее, чем изменение типа существующего реквизита (например, со строки на число). Изменение типа часто требует преобразования данных, что может быть более ресурсоемким.
3. Аппаратное обеспечение сервера: Мы посмотрим, что производительность дисковой подсистемы (особенно SSD-накопители), объем оперативной памяти и мощность процессора как сервера СУБД, так и сервера 1С:Предприятия напрямую влияют на скорость выполнения операций.
4. Состояние индексов и фрагментация: Мы разберем, что высокая фрагментация таблиц и индексов может существенно замедлить процесс реструктуризации. Перед проведением масштабных изменений рекомендуется проверить и, при необходимости, перестроить индексы.

Приведем примеры из практики для лучшего понимания: для 100 000 записей в каком-либо регистре, при старом методе, реструктуризация может занять 2-3 часа. Однако, с использованием нового алгоритма, реструктуризация двух регистров бухгалтерии примерно по 12 млн записей в каждом, плюс таблица с субконто с 47 млн записей, заняла всего 45 минут. Это значительное ускорение, которое мы изучим подробнее.

Механизмы реструктуризации: традиционный и оптимизированный (v2)

Система 1С:Предприятие предлагает несколько подходов к реструктуризации базы данных. Мы разберем два основных механизма: традиционный и оптимизированный, известный как v2.

Традиционный механизм реструктуризации

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

1. Копирование всей таблицы: Мы увидим, что для каждого изменяемого объекта происходит полное копирование всех его данных, что для больших таблиц может занимать очень много времени и требовать значительных ресурсов дисковой подсистемы.
2. Длительность: Мы выясним, что при работе с базами в десятки или сотни гигабайт с миллионами записей, реструктуризация может длиться часами или даже сутками, что часто неприемлемо для рабочих систем.

Оптимизированный механизм реструктуризации (v2)

Начиная с версии платформы 1С:Предприятие 8.3.11, был представлен новый, оптимизированный механизм реструктуризации базы данных (v2), который значительно ускоряет процесс обновления конфигурации. Мы рассмотрим его ключевые особенности и преимущества:

1. Появление и ускорение: Мы проанализируем, что новый механизм появился в версии 8.3.11 и в среднем обеспечивает ускорение в 3-4 раза, а в некоторых случаях — на порядки. Например, для базы в 400 ГБ добавление реквизитов к документам и измерений к регистрам сведений сократило время реструктуризации с 2 часов до 15 минут.
2. Принцип работы: Мы разберем, что v2 минимизирует манипуляции над данными и максимально переносит их на уровень системы управления базой данных (СУБД). Он изменяет только те физические таблицы, в которых есть реальные изменения, и стремится выполнять операции без создания копии таблицы. Если копирование все же требуется, оно выполняется средствами СУБД, что гораздо быстрее, чем построчная обработка сервером 1С.
3. Требования для работы: Мы увидим, что для использования v2 необходимы следующие условия:
   • Работа в клиент-серверном варианте 1С:Предприятия.
   • Использование СУБД Microsoft SQL Server или PostgreSQL.
   • На сервере 1С:Предприятия должна быть установлена Java 8 соответствующей разрядности (32-бит для 32-битного сервера, 64-бит для 64-битного).
4. Активация механизма: Мы рассмотрим несколько способов активации v2:
   • Через файл conf.cfg: Необходимо добавить параметр UseOptimizedDbRestruct = On в секцию [General] файла conf.cfg, который находится в каталоге установки сервера 1С:Предприятия. Также важно убедиться, что для SQL-сервера настроен протокол TCP/IP. После этого при нажатии "Обновить конфигурацию базы данных на сервере" в Конфигураторе будет использоваться новый механизм.
   • В пакетном режиме Конфигуратора: Можно запустить Конфигуратор с соответствующими параметрами командной строки.
5. Особые случаи и версии:
   • Удаление реквизита: Мы выясним, что если в регистре сведений использовался ссылочный тип, а затем связанный документ удален из конфигурации, то при обычном механизме реструктуризации будет копироваться вся таблица регистра. Оптимизированный механизм в этом случае может провести реструктуризацию практически мгновенно, если нет ссылок на удаляемый документ.
   • Изменение составных типов данных (с 8.3.25): Мы узнаем, что с версии 8.3.25 появились новые опции для реорганизации независимых регистров сведений при изменении составных типов данных в измерениях. Настройка "Режим сокращения типа" позволяет выбрать поведение: "Преобразовывать значения" (старое поведение, значения удаленных типов заменяются на "Неопределено"), "Удалять данные" (удаляются записи, связанные с удаленным типом, что уменьшает объем данных и повышает производительность) или "Запрещать" (блокирует обновление, если есть записи с удаленным типом).
   • Индексы в PostgreSQL: Мы проанализируем, что при использовании v2 важно убедиться, что для больших таблиц добавлены недостающие индексы, особенно для PostgreSQL, где для ссылочных полей оптимизированный механизм задает режим хранения PLAIN.
6. Фоновая реструктуризация: Помимо v2, 1С также предоставляет возможность выполнять реструктуризацию в фоне, что позволяет пользователям продолжать работу во время процесса. Однако это также может увеличить общее время выполнения.

Рекомендации для минимизации времени реструктуризации

Чтобы обеспечить максимально быструю и безопасную реструктуризацию базы данных 1С, мы предлагаем следовать этим рекомендациям:

1. Обязательное резервное копирование: Мы подчеркнем, что перед любыми серьезными изменениями конфигурации и реструктуризацией крайне важно создать полную резервную копию базы данных. Это позволит восстановить систему в случае непредвиденных проблем.
2. Использование оптимизированного механизма (v2): Если ваша платформа 1С:Предприятие 8.3.11 или выше и используется клиент-серверный вариант с MS SQL Server или PostgreSQL, мы настоятельно рекомендуем настроить и использовать v2.
3. Тестирование на копии: Мы рассмотрим, что перед применением изменений на рабочей базе, обязательно проведите эксперимент на тестовой копии, чтобы оценить реальное время выполнения и убедиться в корректности всех операций.
4. Очистка итогов: Мы выясним, что перед реструктуризацией, особенно для регистров накопления, может быть полезно очистить итоги. Это может сократить время выполнения, так как не потребуется перестраивать эти данные.
5. Прямое удаление больших объемов данных: Мы разберем, что если планируется удалить миллионы записей (например, старые неиспользуемые данные) до реструктуризации, то программное удаление средствами 1С может быть очень долгим. В таких случаях эффективнее использовать партиционирование таблиц или прямые операции удаления на уровне СУБД (например, SQL-запросы), предварительно убедившись в безопасности таких действий и наличии резервной копии.
6. Внимательность к составным типам: Мы проанализируем, что при изменении составных типов данных в измерениях независимых регистров сведений (начиная с 8.3.25), используйте настройку "Режим сокращения типа" с умом, выбирая "Удалять данные" для максимально быстрого процесса, если удаление соответствующих записей допустимо, или "Запрещать" для контроля целостности.
7. Мониторинг ресурсов: Во время реструктуризации мы рекомендуем активно мониторить нагрузку на диски, процессор и оперативную память сервера, чтобы выявить возможные "узкие места".

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