От экспертов «1С-Рарус»: Обновление базы 1С:ERP размером 1,3 ТБ через копию с технологическим окном 1 час в сутки

Ситуация до обновления базы

Сегодня мы поговорим про один из интересных и познавательных случаев обновления базы данных. Начнем с небольшой вводной информации. Обновлять предстояло базу ERP:

• Версия конфигурации БД — 2.5.5.82.
• Размером 1,3 ТБ.
• 14 млн документов.

Оновной объем документов: Реализация товаров и услуг; Заказ клиента; Корректировка реализации; Счет-фактура; Приобретение товаров; Корректировка приобретения товаров.

Прирост документов 500 тысяч в месяц, прирост базы в объеме составляет порядка 80 ГБ в месяц. Следует отметить, что предприятие, на котором эксплуатировалась данная база данных, имеет непрерывный цикл работы 24/7, доступность базы данных 23/7.

Предпосылки обновления релиза 1С:ERP 2.5.5.82 на релиз 2.5.7.316

Была поставлена задача выполнить обновление конфигурации базы данных до релиза 2.5.7.316. Данным обновлением планировалось решить следующие задачи:

1. Обновление комплекта регламентированной отчетности, а также модулей сдачи отчетности через сервис «1С‑Отчетность».
2. Получение нового функционала, который был внедрен в версиях 2.5.6 и 2.5.7.
3. Исправление ошибок типового решения, конкретно нас интересовало исправление ошибки bugboard.v8.1c.ru/error/000108815. Установка исправлений данной ошибки позволила бы ускорить операцию расчета себестоимости, соответственно сократив общее время на закрытие месяца. Отсталость нашего релиза от релиза, в котором была исправлена данная ошибка не позволяла точечно обновить интересующий нас функционал. Нам требовалось полное обновление до свежего релиза. Релиз, начиная с которого в системе появляется исправление, указан в самой ошибке, подробно на картинке ниже.

   

   Как мы видим на картинке, исправление появились начиная с версий 2.4.13.269, 2.5.6.244, 2.5.7.201. Наличие в списке версии 2.4 никого не должно удивлять, на момент исправления ошибки версия 2.4 находилась на сопровождении, версия с исправлением ошибки 2.4 вышла позднее, чем наш исходный релиз 2.5.5.82.

   

   

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

Этапы обновления базы 1С:ERP

Давайте немного поговорим про обновление, что это вообще такое.

Под обновлением мы подразумеваем процесс установки нового релиза конфигурации от поставщика программного продукта.

Данный процесс можно разбить на 2 основных этапа:

1. Подготовка новой конфигурации и обновление с ее помощью текущей конфигурации базы данных.
   
2. Обновление данных в базе, которое в свою очередь состоит из этапов:
   1. Реструктуризация таблиц базы данных.
      Реструктуризация — процесс обновления структуры таблицы базы данных, который выполняется посредством создания полной копии исходной таблицы. Реструктуризация необходима при изменении метаданных конфигурации (добавляются документы, реквизиты, индексы), ведущих к изменению структуры таблиц. На картинке ниже приведен пример сообщения, которое появляется в конфигураторе после окончания процесса реструктуризации. В случае успешного окончания реструктуризации, кнопка «Принять» активна, при наличии ошибок, они будут зафиксированы в списке, кнопка «Принять» будет неактивна.

      

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

      

      В текущих версиях подсистемы БСП предусмотрена возможность отключить данный процесс обновления для служебных целей, для этого существует ключ запуска ОтключитьЛогикуНачалаРаботыСистемы. Данный ключ позволяет запустить базу данных, без запуска обновлений. Работать пользователям с данным ключом категорически запрещено, данный ключ применяется только администраторами базы в служебных целях, а также в случае возникновения нештатных ситуаций при обновлении. Подробнее про данный ключ можно прочитать в документации its.1c.ru/db/bsp317doc/content/6/hdoc.

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

      

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

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

      

Варианты подготовки релизов для обновления базы

Для подготовки релизов обновления может применяться несколько разных подходов:

• Обновление базы данных без доработок конфигурации.
• Обновление с использованием механизма платформы — сравнение, объединение с конфигурацией поставщика.
• Обновление с использование средств автоматизации обновления конфигураций.
• Обновление в среде EDT.

Обновление базы данных без доработок конфигурации

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

1. Получить файл обновлений типовой конфигурации от поставщика программного продукта.
2. Зайти в конфигуратор.
3. В разделе «Конфигурация\Поддержка» выполнить команду «Обновить конфигурацию».
4. После выполнения поиска доступных обновлений, выбрать версию и запустить процесс. На картинке ниже представлен процесс выбора версии установки обновлений:

   

Обновление с использованием механизма платформы — сравнение, объединение с конфигурацией поставщика

Данный метод является самым распространенным, поскольку используется встроенный механизм платформы «1С:Предприятие». Данный способ представляет собой процесс подготовки релиза доработанной конфигурации при помощи механизма конфигуратора «сравнение/объединение».

В данном методе применяется сравнение 3-х сущностей: конфигурации базы данных, старой конфигурации поставщика и новой конфигурации поставщика.

В случае, когда сравниваемый объект, например форма документа, не имеет различий между конфигурацией БД и старой конфигурацией поставщика, она автоматически забирается из новой конфигурации поставщика, если там были какие-либо изменения.

Когда сравниваемый объект имеет различия между текущей конфигурацией БД и старой конфигурацией поставщика, требуется участие разработчика, для принятия решения об объединении. На изображении ниже мы видим стандартный вид окна сравнения\объединения с результатом сравнения конфигураций:

Сравнение процедур выполняется в отдельном окне. Внешний вид формы сравнения процедур представлен на картинке ниже:

Обновление с использованием средств автоматизации обновления конфигураций

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

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

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

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

Более подробно про «1С-Рарус: СОК» можно узнать в докладе:

Обновление в среде EDT

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

Процесс обновления конфигурации в данной среде существенно отличается от аналогичного процесса в конфигураторе. Первым отличием является отсутствие в EDT понятия «Конфигурация поставщика», одним из решением данной особенности, является хранение конфигурации поставщика в ветке git.

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

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

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

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

Обновление данных в базе «через Копию»

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

Подготовка релиза

Подготовка релиза включает в себя этапы:

1. Выполнения процесса сравнения/объединения обновляемой конфигурации и конфигурации поставщика. Данный этап выполнялся путем запуска процесса обновления в конфигураторе, для этого:
1. В разделе «Конфигурация/Поддержка» выполнялась команда «Обновить конфигурацию».
2. Указывался файл обновлений от поставщика нужной нам версии
3. После выбора файла обновлений запускался процесс сравнения/объединения.
2. Решение коллизионных ситуаций, после выполнения сравнения. В будущем для данного этапа планируем задействовать решение «1С-Рарус: СОК», которое позволяет существенно сократить трудозатраты на выполнение данного этапа.
3. Адаптация ранее выполненных доработок конфигурации к новой конфигурации поставщика.
4. Тестирование подготовленного релиза.

Подготовка правил обмена

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

Подготовка правил выполняется на основании конфигурации «1С:Конвертация данных» версии 2.1.8.2. Правила создаются путем настройки соответствия объектов: документов, справочников, регистров сведений, для каждого объекта настраивается соответствие полей объекта источника и объекта приемника, при необходимости корректировки при загрузке может быть разработан и запущен произвольный алгоритм. Подробнее про «1С:Конвертация данных» можно почитать в документации its.1c.ru/db/metod8dev#browse:13:-1:3199:3210:3219.

Снятие копии эталонной базы

Снятие копии эталонной базы, включение на эталонной базе регистрации изменений на плане обмена.

Подготовка копии базы выполняется средствами СУБД:

Обновление снятой копии

Обновление снятой копии до целевого релиза с запуском всех обработчиков обновления. Данный этап можно выполнить двумя способами:

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

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

Далее следует выгрузка накопленной на плане обмена информации в эталонной базе в обновленную копию. Для этого используется подсистема «Обновление через копию», которая содержит в себе обработчик выгрузки данных. Затем происходит переключение пользователей на работу в обновленной копии.

Подсистема для выполнения обновления через копию встраивается фирмой «1С» в типовое решение ЕРП, также данную подсистему содержат типовые решения «1С:Управление торговлей» и «1С:Комплексная автоматизация». Подсистема обновления через копию включает в себя:

• план обмена;
• обработчики выгрузки и загрузки данных.

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

Определяем последовательность релизов, которые требуются для обновления базы с сохранением консистентности данных

Теперь, когда мы немного погрузились в тему, давайте разберем наш случай. Начнем с анализа задачи и выработки пути ее решения

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

Например, если в типовом релизе происходит замена реквизита регистра — это выполняется в несколько этапов: в первом релизе добавляется новый реквизит и выполняется его заполнение, во втором релизе удаляемому реквизиту присваивается префикс «Удалить» и только в третьем релизе он удаляется.

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

Цепочка релизов получилась следующая 2.5.5.82 (исходный релиз) → 2.5.5.112 → 2.5.5.117 → 2.5.6.290 → 2.5.6.291 → 2.5.7.298 → 2.5.7.316 (целевой релиз). В итоге нам предстояло подготовить 4 промежуточных релиза и 1 финальный:

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

Проводим эксперимент для определения времени, необходимого для обновления

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

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

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

Результаты эксперимента

В результате проверки мы определили:

1. Общее время, которое потребуется на установку всех релизов с обновлением данных — порядка 14 дней.
   
2. Реструктуризация базы данных при установке релизов в пределах подредакции занимала около 24 часов. Реструктуризация при переходе через подредакцию доходила до 2-х суток.

   Действие	Время
   Общее время установки обновлений	14 суток
   Реструктуризация данных в пределах подредакции	24 часа
   Реструктуризации между подредакциями	2 суток

3. После установки финального релиза, силами консультантов, была выполнена проверка работоспособности функционала конфигурации.
   1. Создание и проведение первичных документов.
   2. Работа типовых отчетов.
   3. Работа подсистемы закрытия месяца и расчета финансового результата.
      Проверка работоспособности функционала подтвердила правильность выбранной последовательности установки релизов, а также корректность отработки обработчиков обновления данных.
4. Была обнаружена проблема в обработчике обновления справочника «Объекты расчетов». При выполнении обновления данных в монопольном режиме этот обработчик зависал из-за объемов справочника — в нем было порядка 5 млн записей. Такое количество записей обусловлено использованием детализации расчетов по заказам. Имея от 6 до 10 тысяч заказов каждый день за 18 месяцев жизни базы мы получили справочник в 5 млн записей.

   Мы проанализировали алгоритм обработчика: он предполагал пересоздание каждого элемента справочника «Объекты расчетов». Это требовалось из-за расширения вариантов ведения взаиморасчетов для договоров с контрагентами. В нашем случае элементы объектов расчетов не претерпевали никаких изменений, в связи с этим было принято решение отказаться от выполнения данного обработчика обновления, что позволило нам решить проблему с зависанием монопольного обновления и сократить общее время, требуемое на обновление данных.

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

   1. Регистрация данных на узле обмена «Обновление информационной базы», которые требуется обработать.
   2. Обработка зарегистрированных данных.

   Для пропуска обработчика обновлений мы воспользовались ключом запуска ОтключитьЛогикуНачалаРаботыСистемы. Данный ключ позволил нам запустить базу, без выполнения обработчиков обновления. Далее мы разработали обработку, которая удаляет с плана объекта записи с объектами определенного типа. Используя разработанную обработку мы удалили зарегистрированные объекты с типом «Объект расчетов».

Принятие решения об обновлении 1С:ERP через копию и реструктуризация данных

Проведя анализ полученных результатов, единственным возможным способом обновления был выбран вариант обновления через копию, поскольку недоступность рабочей базы данных, как мы упоминали ранее, не могла быть более 1 часа в день.
Для сокращения времени установки обновлений было принято решение воспользоваться «Оптимизированным механизмом реструктуризации».

Обычная реструктуризация

Реструктуризация — это изменение структуры и состава таблиц базы данных, и перенос имеющихся данных в изменённые таблицы. В традиционном процессе реструктуризации последовательно анализируются все объекты конфигурации. Для каждого объекта выполняется:

1. Анализ его изменений.
2. Создание новых таблиц в базе данных, которые соответствуют новой структуре объекта.
3. Перенос данных.

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

Оптимизированный механизм

В оптимизированном механизме реструктуризации применены следующие идеи:

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

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

Оптимизированный механизм реструктуризации используется только в клиент-серверном варианте работы — для СУБД Microsoft SQL Server или PostgreSQL. Для запуска оптимизированного механизма реструктуризации нам потребуется:

1. Установка Java 8 на все сервера 1С:Предприятие в кластере.
2. Редактирование файла conf на клиентской машине при использовании операционной системы Windows, с которой выполняется запуск Конфигуратора. Файл расположен в каталоге C:\Program Files\1cv8\conf для 64-х разрядной платформы или C:\Program Files (x86)\1cv8\conf для 32-х разрядной.

При использовании Linux путь к файлу conf /opt/1C/v8.3/i386 в случае 32-разрядной версии или в каталог /opt/1C/v8.3/x86_64 в случае 64-разрядной версии.

В файл требуется добавить строку «UpdateDBCfg=v2».

Описание включение реструктуризации представлено в документации: its.1c.ru/db/v8323doc/bookmark/dev/TI000002111.

После чего при запуске обновления конфигурации БД реструктуризация будет выполняться с использованием альтернативного механизма.

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

Данный механизм позволил нам существенно сократить время реструктуризации базы данных. Для промежуточных релизов среднее время реструктуризации составило 8–12 часов, для релизов перехода через подредакцию порядка 24 часов:

Работы по обновлению базы 1С:ERP

После разработки плана обновления были начаты работы, которые включали в себя следующие этапы:

1. Подготовка релизов для обновления промежуточных и финального.
   Промежуточные релизы отличались от финального этапом тестирования функционала. Во время тестирования выполнялась проверка функционала системы в рамках бизнес-процессов заказчика. Тестирование выполнялось только на финальном релизе. Для подготовки релизов использовался классический метод.
   
2. Встраивание подсистемы выгрузки данных в эталонную базу.
   В релизе ERP 2.5.5.82 не была предусмотре подстсиема обновления через копию, в связи с чем она была взята из финальной конфигурации и встроена в эталонную базу для обеспечения возможности накопления изменений и выгрузки данных.
   
3. Подготовка правил обмена для выгрузки данных из эталонной базы в обновленную копию.
   Правила обмена разрабатывались с использование конфигурации «Конвертация данных», редакция 2.1 версии 2.1.8.2.

   Пример настройки правил для документа Реализация товаров и услуг ниже:

   

4. Параллельная разработка тестовых сценариев для проверки обновленной базы данных.
   Тестовые сценарии разрабатывались силами консультантов и представляли собой набор действия пользователя для проверки функциональности системы.
   
5. Тестовый прогон установки релизов, выгрузки и загрузки данных, оценка скорости обмена данными.

Сложности при «Обновлении через копию»

Давайте разберем проблемы и нюансы работы подсистемы «Обновление через копию» из коробки — с чем столкнулись, и что потребовало внесения доработок.

Выгрузка

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

   1. Была реализована выгрузка последовательно по каждому объекту метаданных, которые были накоплены на плане обмена:

      

   2. Один файл выгрузки содержал не более 1 000 объектов. Ограничивая объем объектов в выгрузке мы получаем при загрузке «битые ссылки».

      Битая ссылка — это наличие GUID в поле объекта ссылочного типа, при отсутствии объекта в базе данных, на который ссылается данный GUID.

      Пример, как выглядит битая ссылка в документах на картинке ниже.

      

      Данного факта не стоит пугаться, при загрузке файла, который содержит объект, на который указывает «битая ссылка», ссылка станет рабочей.

2. При выгрузки документов была выполнена сортировка по дате создания, это позволило в дальнейшем отслеживать прогресс по загрузке данных по видам документов.
3. Для ускорения выгрузки и уменьшения объемов файлов при выгрузке объектов все ссылочные типы выгружались как GUID, без выгрузки объектов ссылочного типа.

4. Типовой механизм получения изменений использовал в плане обмена метод «ПланыОбмена.ПрочитатьИзменения». Главной проблемой данного метода является установка блокировки на изменение данных, для которых мы получаем изменения. Данный вариант нам не подходил, поскольку вызывал конфликты блокировок при работе пользователей. Вместо данного метода были использованы запросы к таблицам изменений выгружаемых объектов:

   

Загрузка

Была доработана загрузка на стороне обновленной копии. Типовой механизм обмена предполагал стандартную схему: «Получаем файл обмена» → «Загружаем данные» → «Отправляем подтверждение получения» → «Выгружаем новый файл обмена».

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

1. Было принято решение отказаться от отправки подтверждения успешной загрузки данных.
   
2. Выгрузка данных из эталонной базы выполнялась непрерывно, после выгрузки очередного файла измененные объекты, которые в него попали удалялись из плана обмена.
   
3. При загрузке выполнялся поиск в заданной папке всех файлов, наименование которых подходило под заданный шаблон. Шаблоном было имя «Message_ОбменПорциями_». Код поиска файла в каталоге приведен ниже:

   

4. В случае ошибки загрузки файла он копировался в отдельную папку для анализа и удалялся из основной очереди файлов к загрузке.
   

5. Была доработана постобработка загруженных данных.

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

   Поскольку наше обновление предполагало переход сразу 2-х подредакций, мы отказались от передачи движений документов, а так же обработки полученных данных обработчиками обновлений. Документы загружались не проведенными и регистрировались к проведению.

   Проведение документов выполнялось в отдельно разработанном регламентном задании, которое включало в себя многопоточное проведение документов с делением по складам, для обеспечения оптимальной скорости проведения и отсутствии взаимных блокировок. Документы проводились с учетом требований к последовательности документооборота, например первым проводился документ «Заказ покупателя», затем «Реализация товаров и услуг», далее, при наличии, документ «Корректировка реализации».

Действия после установки релизов на копию базы

После окончания установки релизов на копию базы, нам потребовалось порядка 3-х недель для загрузки всех накопленных данных и достижения требуемого времени на загрузку остатков объектов равному технологическому окну.

На данном этапе для переключения работы пользователей в новую базу нам оставалось выполнить следующие действия:

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

   

Рекомендации

Проведя анализ результатов выполненного обновления, хочется поделиться советами, которые стоит учесть в будущем:

• Требуется обеспечить поддержание актуального релиза, проводить обновление регулярно.
  
• В случае, если у нас возникла необходимость ликвидировать длительный разрыв между обновлениями, не надо гнаться за последним релизом, переход через 2 подредакции для конфигурации типа ERP является достаточно сложным и объемным, поскольку содержит в себе большое количество изменений, что влечет за собой увеличение времени на обновление и дальнейшее «Обновление через копию» — это затягивание времени на загрузку данных. Оптимально в нашей ситуации был бы переход только через 1 подредакцию, за один цикл обновлений.
  
• Для комплексного тестирования после подготовки обновлений оптимально использовать автотесты. Они требуют больших трудозатрат при первичном составлении, но в дальнейшем позволят качественно улучшить тестирование и новых обновлений, и обычных доработок функционала.

Подробно про автотесты:

Заключение

• При подготовки обновления объемных баз данных всегда проводите исследование возможности обновления. Таким образом вы получите представление о времени, которое потребуется для установки обновлений, и сможете обнаружить потенциальные проблемы в обработчиках обновлений, которые не всегда хорошо оптимизированы.
• Существуют разные подходы к подготовке релизов обновления, что позволяет выбрать наиболее подходящий метод для конкретного случая.
• «Обновление через копию» является рабочим механизмом, но требует анализа работы предлагаемых алгоритмов и их оптимизации.
• Откладывание обновления «на потом» приводит к повышенным разовым трудозатратам на подготовку обновлений. Рекомендуем не затягивать с обновлениями, в случае выбора стратегии обновляемости системы не допускать сильного отставания системы от последней версии поставщика.