Мы сталкиваемся с распространенной проблемой: после добавления новой табличной части (ТЧ) или реквизита в документ в конфигурации 1С, процесс сохранения изменений, который включает в себя реструктуризацию базы данных, может затянуться на долгие часы, а порой и на целый день. Это серьезно замедляет разработку и обновление информационных систем. Давайте подробно разберем, почему возникает такая длительная реструктуризация, как ее диагностировать и какие существуют эффективные способы ее ускорить.
Когда мы сталкиваемся с тем, что обновление конфигурации базы данных занимает час или более, первым делом возникает вопрос о корневой причине такого поведения. Мы выяснили, что в нашем случае длительную реструктуризацию вызывала табличная часть «Товары», содержащая 48 миллионов строк, хотя изменения в метаданных напрямую к ней не относились.
Исторически платформа 1С:Предприятие использовала механизм реструктуризации, который можно условно назвать V1. Его принцип работы заключался в следующем:
Этот процесс, по сути, представляет собой последовательность операций копирования, вставки и удаления. Для таблиц с большим объемом данных (десятки миллионов строк, как в нашем случае с 48 миллионами строк в ТЧ «Товары») такая процедура требует значительного времени и ресурсов СУБД, существенно увеличивая размер лог-файлов. Если реструктуризация была прервана ранее, в базе данных мог остаться так называемый "флаг", который при любом последующем изменении метаданных данного объекта вызывает его полную реструктуризацию, даже если изменяются несвязанные реквизиты.
Чтобы точно понять, что именно происходит в СУБД во время длительной реструктуризации, мы можем использовать инструмент SQL Server Activity Monitor. Он позволяет в реальном времени отслеживать активности на сервере SQL.
SQL Server Management Studio (SSMS) нажмите правой кнопкой мыши на экземпляре сервера в Object Explorer и выберите пункт меню Monitor Activity.Processes. Отсортируйте процессы по состоянию, чтобы наиболее активные находились в верхней части списка.В нашем случае, именно SQL Server Activity Monitor помог выявить, что длительную реструктуризацию вызывала табличная часть Товары, содержащая 48 миллионов строк, несмотря на то, что изменения в метаданных напрямую к ней не относились. Это подтвердило подозрения о возможном "флаге" прерванной реструктуризации, оставшемся в базе данных.
Начиная с платформы 1С:Предприятие 8.3.11, был введен оптимизированный механизм реструктуризации (V2), который значительно ускоряет процесс для больших баз данных, избегая полного копирования строк и минимизируя операции с данными.
V2 — это совершенно новый подход, который стремится максимально перенести операции по изменению структуры на уровень самой СУБД. Главное отличие V2 заключается в том, что он в большинстве случаев избегает полного копирования строк из старых таблиц в новые. Вместо этого, для многих операций (таких как добавление реквизита в шапку документа) V2 использует операции ALTER TABLE напрямую, изменяя существующую таблицу. Например, при добавлении реквизита в шапку документа, изменяется только таблица шапки, а связанные с документом табличные части не затрагиваются, что исключает их полное копирование.
Это приводит к существенному ускорению. По данным 1С, V2 способен реструктурировать табличную часть с 80 миллионами строк (с добавлением индексов) за 35 минут, а периодический регистр сведений со 100 миллионами строк (с построением индексов) — за 1 час 20 минут.
Чтобы активировать оптимизированный механизм V2, необходимо выполнить ряд настроек:
conf.cfg:
conf.cfg в каталоге установки 1С:Предприятия на сервере (например, C:\Program Files\1cv8\conf).
UpdateDBCfg=v2
conf.cfg на клиентской машине, с которой запускается конфигуратор, также может влиять на выбор механизма реструктуризации. Убедитесь, что там тоже указано v2 или отсутствует параметр UpdateDBCfg, чтобы не переопределять серверные настройки.Java (JRE) версии 1.8 (Java 8) или выше. Установите JRE на компьютере, где установлен сервер 1С:Предприятия. Рекомендуем использовать версию jre1.8.0_311 или новее, а лучше — дистрибутив Java, рекомендованный 1С для работы с платформой.JavaHome файла conf.cfg, если платформа не находит его автоматически через переменную окружения JAVA_HOME или системный реестр Windows.Microsoft SQL Server или PostgreSQL.Microsoft SQL Server должен использоваться сетевой протокол TCP/IP. Работа оптимизированного механизма реструктуризации не поддерживается в том случае,
если сервер «1С:Предприятия» подключается к СУБД Microsoft SQL Server с использованием сетевых протоколов Разделяемая память или Именованные каналы. Мы можем проверить используемые протоколы соединений с помощью следующего SQL-запроса:
SELECT program_name, net_transport
FROM sys.dm_exec_sessions AS t1
LEFT JOIN sys.dm_exec_connections AS t2 ON t1.session_id=t2.session_id
WHERE NOT t1.program_name IS NULL
conf.cfg и установки Java, обязательно перезапустите службу агента сервера 1С:Предприятия.
Конфигурация → Конфигурация базы данных → Обновить конфигурацию базы данных на сервере
При включении V2 пользователи часто сталкиваются с различными ошибками. Рассмотрим наиболее распространенные и способы их устранения:
lpc:). Java-компоненты могут не понимать такие префиксы, ожидая имя сервера в формате, используемом для сетевого доступа.TLSv1 в Java: В некоторых версиях Java (особенно более старых JRE 1.8) может возникать ошибка из-за отключенного протокола TLSv1. Чтобы исправить это, найдите файл java.security в каталоге C:\Program Files\Java\jre1.8.0_XXX\lib\security (где XXX — ваша версия Java). В этом файле найдите опцию jdk.tls.disabledAlgorithms и удалите из списка TLSv1. После этого строка должна выглядеть примерно так:
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, \
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves
UpdateDBCfg=v2 в conf.cfg (на сервере и, при необходимости, на клиенте), перезапуск службы сервера 1С, корректность установки Java, использование TCP/IP для соединения с СУБД.
Конфигурация → Конфигурация базы данных → Обновить конфигурацию базы данных на сервере
conf.cfg: Как было замечено в обсуждении, файл conf.cfg на клиентской машине может переопределять настройки сервера. Если вы запускаете конфигуратор с клиентской машины, убедитесь, что её conf.cfg также настроен на v2 или вовсе не содержит параметра UpdateDBCfg, чтобы настройки сервера имели приоритет.Важное предупреждение: Механизм V2, будучи быстрым и эффективным, не предоставляет возможности остановить процесс реструктуризации после его запуска стандартными средствами. Принудительное прерывание V2 может привести к повреждению системных таблиц базы данных и потребовать восстановления из актуальной резервной копии.
В случае, если активация V2 невозможна или вы столкнулись с уникальной ситуацией (например, подозреваете "флаг" прерванной реструктуризации, как в нашем исходном случае), можно применить ручной обходной путь, используя возможности SQL Server. Этот метод требует глубокого понимания структуры базы данных и работы с SQL, и его следует применять с крайней осторожностью и только на копиях баз данных.
SQL Server Activity Monitor определите имя таблицы в СУБД, которая вызывает длительную реструктуризацию (например, таблица ТЧ Товары).SQL Server Management Studio, переименуйте проблемную таблицу (например, из _Document_Goods в _Document_Goods_OLD)._Document_Goods_OLD).Script Table as → CREATE To → New Query Editor Window._Document_Goods) и выполните скрипт, чтобы создать пустую таблицу с правильной структурой._Document_Goods) во что-то временное (например, _Document_Goods_TEMP)._Document_Goods_OLD) обратно в оригинальное имя (_Document_Goods)._Document_Goods_TEMP).Этот метод позволяет "обмануть" 1С, заставив его быстро завершить реструктуризацию, после чего вы вручную восстанавливаете оригинальные данные. Однако он очень рискован и требует глубокого понимания работы СУБД, поэтому его следует применять только как крайнее средство при невозможности использования V2.