Обновление на разных платформах 1С: будут ли базы идентичны по структуре и скорости работы?

← На главную

При переходе со старых редакций конфигураций на новые (например, при масштабном обновлении «Бухгалтерии предприятия 2.0» на редакцию 3.0) перед ИТ-специалистами часто встает вопрос выбора версии платформы «1С:Предприятие». Иногда среди системных администраторов возникает гипотеза: если выполнить сам процесс обновления на более старой версии платформы (например, 8.3.10), а затем запустить готовую базу на актуальной версии (например, 8.3.12), то такая база будет работать быстрее, чем если бы обновление сразу выполнялось на новой платформе.

В этой статье мы подробно разберем, как платформа 1С управляет структурой баз данных СУБД, как работают механизмы реструктуризации, и действительно ли версия платформы в момент обновления влияет на последующую производительность системы. Мы проанализируем внутреннее устройство платформы и составим пошаговый план для получения максимально быстрой и стабильной информационной базы после перехода.

Как платформа 1С проектирует структуру таблиц в СУБД

Для начала проанализируем, от чего вообще зависит физическая структура таблиц в СУБД (MS SQL Server, PostgreSQL, IBM DB2 или Oracle Database) при работе с «1С:Предприятием». Логическая структура базы данных описывается метаданными конфигурации (справочники, документы, регистры, их реквизиты и табличные части). Физическая же структура (имена таблиц вида _ReferenceXX, типы колонок, наличие индексов) формируется платформой на основе двух ключевых параметров:

Состав объектов метаданных конфигурации. Если мы обновляем две копии одной и той же базы до одного и того же релиза конфигурации (например, БП 3.0.XX.XX), состав метаданных в них гарантированно становится абсолютно одинаковым.
Режим совместимости конфигурации. Это важнейшее свойство конфигурации, которое указывает платформе, стандарты какого релиза нужно использовать при работе с базой данных. Если у конфигурации установлен режим совместимости «Версия 8.3.10», то даже при запуске базы под платформой 8.3.12 СУБД будет использовать правила построения запросов и таблиц, характерные для версии 8.3.10.

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

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

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

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

Выясним причину разницы между старым и новым механизмами:

Старый механизм реструктуризации (v1) в платформе 8.3.10 и ниже: При изменении структуры метаданных (например, добавлении нового реквизита в крупный справочник или регистр) платформа создавала в СУБД временную таблицу, построчно копировала туда все данные силами сервера приложений 1С, удаляла старую таблицу и переименовывала временную. На больших базах данных этот процесс мог занимать десятки часов и требовал огромного дискового пространства.
Новый механизм реструктуризации (v2), появившийся в 8.3.11: Теперь большинство операций по изменению структуры СУБД выполняются непосредственно силами самой СУБД с помощью быстрых DDL-команд (например, ALTER TABLE). Построчное копирование данных сервером 1С исключено там, где это возможно. Это позволило ускорить процесс обновления структуры базы данных в разы (а на некоторых операциях — в десятки раз).

Отсюда следует важный практический вывод: обновление конфигурации под управлением новой платформы (например, 8.3.12) пройдет значительно быстрее, чем под управлением старой 8.3.10, именно благодаря оптимизированному механизму реструктуризации версии v2. Конечный же физический вид таблиц после завершения реструктуризации будет одинаковым в обоих случаях.

Разбор мифа: «На старой платформе после обновления база работает быстрее»

Почему же у некоторых специалистов (включая системных администраторов) возникает ощущение, что база, обновленная под старой платформой, работает быстрее? Проанализируем ситуацию и выявим реальные причины замедления работы базы сразу после масштабного обновления (например, перехода с редакции 2.0 на 3.0):

Отложенное обновление данных (БСП). Современные конфигурации (включая БП 3.0) построены на базе Библиотеки Стандартных Подсистем (БСП). После того как физическое обновление конфигурации в конфигураторе завершено, при первом запуске в пользовательском режиме стартуют так называемые отложенные обработчики обновления. Они в фоновом режиме переносят данные из старых структур в новые, заполняют новые регистры, пересчитывают итоги. Этот процесс создает колоссальную нагрузку на дисковую подсистему и процессор сервера. Если начать замерять скорость работы пользователей в этот момент, система покажется крайне медленной.
Регламентные и фоновые задания. В редакции БП 3.0 по умолчанию включено огромное количество регламентных заданий, которых просто не существовало в БП 2.0. Это полнотекстовый поиск (ФТП), автоматическая загрузка курсов валют, классификаторов, новостей, интеграция со сторонними сервисами (СПАРК Риски, Контрагент и др.). Все они регулярно запускаются в фоне, отнимая ресурсы сервера.
Устаревшая статистика СУБД и фрагментация индексов. Во время глобальной реструктуризации при переходе на новую редакцию таблицы базы данных полностью перестраиваются СУБД. При этом старая статистика распределения данных, которой пользовался оптимизатор запросов СУБД, становится неактуальной, а индексы сильно фрагментируются. Без принудительного обслуживания СУБД запросы начнут выполняться по неоптимальным планам, вызывая сильные «тормоза».

Следовательно, миф о превосходстве старой платформы при обновлении несостоятелен. Медленная работа обусловлена исключительно фоновыми процессами прикладного решения и отсутствием регламентного обслуживания СУБД после завершения перехода.

Пошаговое руководство по правильному переходу на БП 3.0 для обеспечения максимальной скорости

Чтобы гарантировать идеальную чистоту структуры базы данных, отсутствие логических ошибок и максимальное быстродействие, выполним переход по следующему проверенному алгоритму.

Шаг 1. Подготовка и обновление платформы

Установим на сервер приложений 1С актуальную рекомендованную версию платформы (например, 8.3.12 или выше). Выполнять переход на устаревших версиях платформы крайне не рекомендуется из-за отсутствия оптимизаций работы с памятью и СУБД.

Шаг 2. Обновление конфигурации в режиме конфигуратора

Запустим процесс обновления конфигурации БП 2.0 до редакции 3.0 под управлением новой платформы. Платформа задействует быстрый механизм реструктуризации v2, что существенно сэкономит время проведения работ.

Шаг 3. Использование механизма выгрузки/загрузки через файл .dt

Для того чтобы полностью исключить физическую фрагментацию таблиц на уровне СУБД, очистить базу от временного «мусора», оставшегося после тяжелого процесса реструктуризации, и пересоздать все индексы СУБД с нуля по оптимальным алгоритмам новой платформы, выполним процедуру пересоздания базы через файл выгрузки:

В конфигураторе обновленной базы выберем пункт меню Администрирование — Выгрузить информационную базу... и сохраним файл .dt.
В СУБД (например, в MS SQL Server) создадим новую пустую базу данных.
Добавим эту пустую базу в список информационных баз 1С.
Запустим ее в режиме конфигуратора, выберем пункт меню Администрирование — Загрузить информационную базу... и выберем ранее сохраненный файл .dt.

При загрузке файла .dt платформа 1С заново генерирует физическую структуру таблиц в базе данных СУБД под управлением текущей версии платформы, обеспечивая её идеальное состояние.

Шаг 4. Управление регламентными заданиями

Запустим базу в пользовательском режиме и дождемся завершения всех отложенных обработчиков обновления БСП (за их состоянием можно следить через форму «Результаты обновления программы»). После этого отключим неиспользуемые регламентные задания, которые создают лишнюю фоновую нагрузку.

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


ВыборкаЗаданий = РегламентныеЗадания.ПолучитьРегламентныеЗадания();
Для Каждого ТекущееЗадание Из ВыборкаЗаданий Цикл
    // Отключим, например, полнотекстовый поиск и извлечение текста, если они не используются
    Если Найти(ТекущееЗадание.Метаданные.Имя, "ПолнотекстовыйПоиск") > 0 
       Или Найти(ТекущееЗадание.Метаданные.Имя, "ИзвлечениеТекста") > 0 Тогда
        
        Попытка
            ТекущееЗадание.Использование = Ложь;
            ТекущееЗадание.Записать();
            ЗаписьЖурналаРегистрации("Оптимизация", УровеньЖурналаРегистрации.Информация, , , 
                "Отключено регламентное задание: " + ТекущееЗадание.Метаданные.Синоним);
        Исключение
            ЗаписьЖурналаРегистрации("Оптимизация", УровеньЖурналаРегистрации.Ошибка, , , 
                "Не удалось отключить задание: " + ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
        КонецПопытки;
        
    КонецЕсли;
КонецЦикла;

Шаг 5. Обслуживание базы данных на уровне СУБД

После того как база данных полностью развернута и все фоновые обработчики обновления завершили свою работу, критически важно выполнить регламентные процедуры на сервере СУБД:

Обновление статистики (Update Statistics). Это заставит СУБД заново проанализировать распределение данных в новых таблицах и строить максимально эффективные планы выполнения SQL-запросов.
Реиндексация таблиц (Reindex). Устранит фрагментацию индексов, которая неизбежно возникает при массовой записи данных во время перехода на новую редакцию.

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