"Обновление через копию" - как это использовать?

17.04.22

Описание того, как использовать "Обновление через копию" для крупных баз данных типа 1С:ERP.

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование		По подписке [?]	Купить один файл
КД_3_1_1_6_ПрописатьВПКОДокументовРежимЗаписиЗапись.epf .epf 7,23Kb 19	19	Скачать (1 SM)	Купить за 1 850 руб.
ЧислоОбъектовОтложенноеОбновление.epf .epf 17,48Kb 12	12	Скачать (1 SM)	Купить за 1 850 руб.
ЧислоОбъектовОбновлениеЧерезКопию.epf .epf 17,52Kb 10	10	Скачать (1 SM)	Купить за 1 850 руб.

Статья пока носит даже, больше так сказать, собирательный характер (общим вселенским разумом допишем её, если что не так), так как я сам пока не знаю на 100%, как правильно использовать этот механизм, убил немало времени на то, чтобы понять хоть что-то, но надеюсь, меня комментаторы ткнут носом в ошибки и я их исправлю в статье.

Предполагаю, что если вы это читаете, то, значит, вы уже обновили хотя бы один раз свою базу данных, например, с ERP 2.4.13 на ERP 2.5.7 и осознали, что это занимает ОЧЕНЬ много времени, потом вы произвели доработку-переработку всех своих изменений под 2.5.7 (кто-то кодит прям в основной конфигурации, а кто-то в расширениях, а кто-то и там, и там), все работает, ошибок нет, все готово и теперь нужно повторно обновлять базу, но уже живую/боевую.

Поехали!

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

Заниматься этим вопросом я стал еще в июне 2021, у меня в распоряжении была база данных с расширениями конфигураций, меняющими данные. На тот момент времени фирма 1С выпустила КД 3.1, который мог уже формировать правила обмена для использования их в этом механизме, но информации, как и что делать, в КД 3.1 я так и не нашел. КД 3.1 на тот момент мог подготовить правила обмена, но только для тех конфигураций, где нет расширений. Да, был способ сделать правила обмена и в случае использования расширений, но тратить время на рассказы про это уже нет смысла, так как недавно был выпущен КД 3.1.1.5, который позволяет создавать правила обмена с учетом имеющихся расширений конфигураций и без дополнительного значительного труда с вашей стороны.

В недрах конфигурации 1С ERP можно найти такое скупое описание процесса обновления через копию.

Обновление через копию

Ограничения и дополнительные рекомендации по работе:
• Обновление через копию предназначено для использования в клиент-серверных ;
• все интерактивные действия выполняются администратором приложения;
• в обновляемой копии не рекомендуется выполнять какие-либо работы до окончания обновления через копию;
• механика не рассчитана на обновление информационных баз с настроенной синхронизацией типа РИБ;
• подсистема Обновление через копию рассчитывает, что до начала работы все предыдущие обновления будут завершены, в т.ч. и отложенные обработчики предыдущих обновлений.
Пошаговое описание сценария обновления.
№	ДЕЙСТВИЕ АДМИНИСТРАТОРА	ИНФОРМАЦИЯ
1	Принять решение о начале обновления и проверить наличие необходимых инструментов: • наличие свободных ресурсов на серверах (место, производственные мощности). Важно учесть, чтобы обновление ИБ "Новой" не привело к ухудшению текущей работы пользователей; • правила конвертации из ИБ "Текущая" в ИБ "Новая", при необходимости изготовить самостоятельно (см. ниже);
2	Включить обновление через копию. Вызвать помощник настройки выгрузки данных можно из раздела Администрирование-Обслуживание группа команд Обновление.
3	Загрузить помощником в ИБ "Текущая" правила конвертации.
4	Включить регистрацию изменений.
5	Инструментами СУБД создать копию данных ИБ "Текущая".
6	Из копии, которую сделали в предыдущем пункте, создать ИБ "Новая".
7	Войти в ИБ "Новая" и включить признак копии: необходимо отключить все операции пользователей, которые могут навредить "Текущей" ИБ.	Пример операций, которые необходимо отключить: • получение почты; • рассылка отчетов; • синхронизация данных;
8	В ИБ "Новая" штатными средствами выполнить обновление на новую версию: загрузить новую версию, произвести первый запуск, при необходимости обновить платформу.
9	В помощнике отметить, что копия сделана.
10	Выполнить настройку транспорта обмена в ИБ "Текущая" (настроить отправку данных для ИБ "Новая") и расписания обменов.
11	После окончания недоступности ИБ "Новой" (реструктуризация и монопольные обработчики обновления) завершить настройку транспорта и расписания обмена на стороне ИБ "Новая", после необходимо включить загрузку данных.	Отправляется накопленная дельта данных.
12	Рассчитать скорость выполнения триады операций: отправка-загрузка-обновление данных, которые переносятся из ИБ "Текущая" в ИБ "Новая". Выполнить прогнозирование времени ключевой операции. Прогноз выполняется самостоятельно.
14	Подготовиться к проведению ключевой операции в ИБ "Текущая": • выполнить команду "Обновление завершено" в помощнике; • заблокировать регламентные задания; • завершить сеансы пользователей; • включить запрет авторизации пользователей; • при необходимости удалить ИБ "Текущая" или перевести в архив.
15	Выполнить ключевую операцию: • перевести ИБ "Новая" в состояние ИБ "Текущая".

Давайте возьмем этот документ за основу и пойдем по пунктам:

Термин ИБ "Текущая" я избегаю и использую термин ИБ "Старая". Текущей ИБ является та ИБ, в которой ты сам сидишь сейчас, и это путает.

Пункт №1

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

Вот тут меня сразу бесит такой момент

правила конвертации из ИБ "Текущая" в ИБ "Новая", при необходимости изготовить самостоятельно (см. ниже)

Куда ниже смотреть? На что? Описания там ниже нет никакого как эти правила готовить/выпекать/сочинять...

Стоит сразу здесь же начать описывать как эти правила обмена делать нужно.

Подготовка:

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

Нам нужна еще база данных КД 3.1.1.6.

Вам нужно найти желательно производительный жесткий диск или SSD, где есть свыше 15 гигабайт свободного места.

Выгрузка метаданных из баз данных ERP старой и новой:

Нужно зайти в конфигуратор базы 2.4.13 и 2.5.7 и там выбрать в меню "Конфигурация / Выгрузить конфигурацию в файлы...",

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

d:\ERP_MET\ERP2413\
d:\ERP_MET\ERP257\

Если у вас есть расширения конфигураций, то вам нужно выгрузить их тоже в файлы.

В списке расширений конфигураций тоже есть команда "Конфигурация / Выгрузить конфигурацию в файлы...".

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

Предварительная настройка КД 3.1:

Когда все выгружено в файлы, далее нам нужна база данных КД 3.1.1.6, которую наверное нет смысла делать серверной, и просто можно сделать файловую на том же производительном диске.

Когда зайдете в базу данных КД, то нужно сперва сделать настройки которые позволят включить отключенный функционал программы. Открываются настройки командой "Администрирование / Используемый функционал" и там включаем две настройки:

"Использовать формат XML"
"Использовать правила регистрации объектов"

Загрузка метаданных в КД 3.1:

Теперь нужно загрузить по очереди в базу данных, то что было ранее выгружено в

d:\ERP_MET\ERP2413\
d:\ERP_MET\ERP257\

Загрузку делаем в специальной обработке, которая вызывается командой "Конфигурации / Сервис / Загрузка структуры конфигурации из файлов XML/EDT".

В окне обработки нужно задать настройки:

"Каталог с файлами для загрузки" указываем каталог, где находится структура конфигурации, которую мы недавно туда выгрузили.
"Источник данных" указываем как "Файлы XML" (если у вас используется EDT вместо конфигуратора, то вы сообразите, что делать). Если выбрать некорректно, то при загрузке вас программа обматерит, что не хватает некоторых файлов и все зафейлится.
"Загрузка движений документов" задаем как "Загружать все".
"Способ загрузки" задаем "В новую версию конфигурации". Я вообще рекомендую, если накосячили с загрузками, лучше сносить базу данных и по новой загружать данные, так как что-то процесс обновления существующих конфигураций ну не быстрый я бы мягко сказал...
Из новшеств загрузки в КД 3.1.1.5 стоит отметить, что в момент загрузки основной конфигурации теперь можно указывать расширения конфигураций с которыми та используется, для этого нужно установить флаг "Есть расширения конфигураций" и в появившемся списке указать все каталоги куда вы выгрузили расширения относящиеся именно к этой версии основной конфигурации. Для второй конфигурации соответственно нужно указать тоже каталоги с расширениями, но уже адаптированными под нее. При загрузке основной конфигурации и расширений получится как бы типа гибридная конфигурация, которая в себе содержит одновременно все объекты метаданных расширений и основной конфигурации. Этот же эффект вы могли наблюдать, когда выгружали метаданные для КД 2.1 при помощи обработки MD83Exp.epf.
Жмем кнопку "Выполнить загрузку".

Создание правил обмена/регистрации в КД 3.1:

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

Правила обмена из старой базы ERP в новую ERP:

Начнем с самого сложного, изготовим правила обмена для выгрузки объектов из старой базы в новую, для этого вызовем обработку командой "Конвертации / Сервис / Автогенерация правил конвертации XML":

В поле "Конфигурация источник" укажем конфигурацию 2.4.13.
В поле "Конфигурация приемник" укажем конфигурацию 2.5.7.
В поле "План обмена" укажем "ПланОбменаСсылка.ОбновлениеЧерезКопию". Обработка создаст правила выгрузки только для тех объектов, которые указаны в составе выбранного плана вида обменов, а так как у нас сейчас цель обновление через копию, то именно его и выбираем, и тут как раз и важно чтобы как писалось выше, чтобы в расширениях конфигураций тоже были такие же планы видов обмена и в них добавлено все не типовое, что создано в расширениях.
В поле "Способ загрузки" укажем "В новую конвертацию". Помним, что обновление старых идет куда дольше создания новых, хотя тоже нужно понимать, что когда база пухнет она не делается производительнее.
Ставим галку в поле "Создать ПКС для движений документов". ТУТ ВОПРОС К ЗНАТОКАМ, НУЖНО ЛИ БЫЛО ЭТО ДЕЛАТЬ ДЛЯ ОБНОВЛЕНИЯ ЧЕРЕЗ КОПИЮ?
Жмем кнопку "Создать правила конвертации".

Будут созданы правила обмена типа таких "УправлениеПредприятием 2.4.13.281 -> УправлениеПредприятием 2.5.7.279".

И тут наступает боль, нужно во все правила конвертации документов прописать алгоритм обработчика события "Перед загрузкой", где нужно указать:

РежимЗаписи = "Запись";

По этому случаю я запилил обработку "КД_3_1_1_6_ПрописатьВПКОДокументовРежимЗаписиЗапись.epf", в которой можно выбрать интересующую вас "Конвертацию", обработка найдет все ПКО документов к ней относящиеся и пропишет в них указанный выше алгоритм. Работоспособность проверена на КД 3.1.1.6.

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

Правила обмена из новой базы ERP в старую ERP:

Нам нужно создать правила обмена в противоположную сторону, но их мы создадим вручную.

Вызываем "Конвертации / Конвертации".
Жмем кнопку "Создать".
В выпадающем меню выбираем "Создать конвертацию XML".
На вкладке "Настройки конвертации XML" укажем в поле "Конфигурация источник" конфигурацию 2.5.7, а в поле "Конфигурация приемник" конфигурацию 2.4.13. Наименование придется задать вручную например так "УправлениеПредприятием 2.5.7.279 -> УправлениеПредприятием 2.4.13.281".
Жмем кнопку "Записать и закрыть".

Эти правила по сути пустышка, по ним ничего не будет выгружаться, но они нужны!

Правила регистрации объектов в старой базе данных ERP:

Далее нам нужны правила регистрации объектов, которые тоже нужно создать вручную:

"Регистрации / Регистрации".
Жмем кнопку "Создать".
В поле "Конфигурация" указываем конфигурацию 2.4.13.
"Имя плана обмена" задаем как "ОбновлениеЧерезКопию". Регистрации будут описаны для всех входящих в план видов обмена объектов, но только в момент выгрузки файла правил на диск, поэтому не делаем лишних телодвижений.
В качестве значения поля "Выгрузка правил производится" задаем "в файл XML".
Жмем кнопку "Записать и закрыть".

Выгрузка созданных правил из КД 3.1 на диск:

В КД 3.1 все сделано, нужно только все это выгрузить на диск в файлы XML.

Правила обмена обмена выгружаются при помощи обработки "Конвертации / Сервис / Выгрузка конвертации XML":

В поле "Конвертация" указываем сначала конвертацию из 2.4.13 в 2.5.7.
Имя файла задаем как "D:\ПРАВИЛА ДЛЯ СТАРОЙ БАЗЫ\ExchangeRules.xml".
Жмем кнопку "Выполнить выгрузку".

Потом выгружаем аналогичным образом правила обмена из 2.5.7 в 2.4.13, но указываем имя файла как "D:\ПРАВИЛА ДЛЯ СТАРОЙ БАЗЫ\CorrespondentExchangeRules.xml".

Потом выгрузим регистрацию в файл, для этого воспользуемся обработкой "Регистрации / Сервис / Выгрузка регистрации":

В поле "Регистрация" указываем регистрацию объектов для 2.4.13
В поле "Имя файла правила" указываем имя файла "D:\ПРАВИЛА ДЛЯ СТАРОЙ БАЗЫ\RegistrationRules.xml".
Жмем кнопку "Выполнить выгрузку".

Создание пакета правил обмена для старой базы ERP:

У нас теперь есть три XML файла правил "ExchangeRules.xml", "CorrespondentExchangeRules.xml" и "RegistrationRules.xml", которые мы упаковываем в один ZIP архив чтобы потом его скормить базе данных 2.4.13. В архиве должны быть только сами файлы, без всяких вложенных папок. Имя файла архива задаете по своему желанию.

Можно создать батничек, который будут делать архив, но при условии, что у вас на ПК установлен 7Zip х64 архиватор. Назвать можно файл как "СоздатьПакетПравилОбмена.bat" и бросить его рядом с XML файлами.
Внутри батника нужно добавить всего одну строку.
"C:\Program Files\7-Zip\7z.exe" a "RulesForOldERP.zip" "ExchangeRules.xml" "CorrespondentExchangeRules.xml" "RegistrationRules.xml"

При запуске батника будет создаваться обновленный файл "RulesForOldERP.zip", который в базу и нужно грузить.

P.S.

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

Как это сделать?

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

Вариант второй, - это прям в созданных автоматически правилах обмена в КД 3.1, создать обработчики событий после загрузки данных, в которых и прописать замену одного значения на другое или еще какие хитрые алгоритмы. Все это по сути разовое действие нужное для обновления на конкретный новый релиз и потом эти правила обмена уже не нужны будут. Недоставки этого метода видны в описании первого метода, когда у разработчиком неумолимая тяга есть к постоянным изменениям доработок и тогда правка правил обмена выльется в утомительную работу.

Пункт №2

Сразу замечание, что если в старой базе данных еще не включена настройка, говорящая, что в базе данных вообще в принципе используется синхронизация данных, то самое время это сделать. Идем в "НСИ и администрирование / Настройка интеграции / Синхронизация данных" и ставим там галку "Синхронизация данных". Это дополнительное условие такое для работы механизма обновления через копию.

Так же порекомендовал бы еще в старой базе указать "Администрирование / Обновление / Обновление программы / Приоритет обработки данных" как "Обработка данных N потоками", где указать N даже наверное большим, чем число доступных ядер процессора +20%, 1С так кисло использует ядра зачастую, что лучше пусть запустится больше фоновых заданий, которые там потихоньку будут копошиться и выполнять больше заданий. Но делайте эти настройки конечно с оглядкой на свои системные ресурсы, а то процессоры с частотой 2.2 ГГц могут вообще захлебнуться от большого числа потоков. Фирма 1С не рекомендует задавать значение больше, чем физически есть ядер. Экспериментируйте.

Фирма 1С говорит, что нужно в старой базе данных запускать режим обновления через копию путем установки галки "Обновление через копию". Галка эта находится в "Администрирование / Обновление / Обновление программы". Процесс, мягко сказать, необратим. Придется, если что через константы лазить снимать галку.

В этот момент станет доступна ссылка "Действие выполняется в текущей ИБ", нажимая которую откроется типа помощника обновления.

Пункт №3

В помощнике первым делом нужно нажать по первой ссылке "Загрузить правила конвертации данных":

Выбрать "Из файла на компьютере". Если выбрать "Из конфигурации", то это ни к чему хорошему не приведет, так как в конфигурации зашиты бесполезные пустышки правил.
Нажать кнопку "Загрузить".
Выбрать с диска наш недавно полученный ZIP архив пакета правил обмена в Пункте №1. После этого программа подумает некоторое время (файлик правил обмена у нас получился, если что свыше 100 мегабайт!). Ждём... Ждём...
Нажать кнопку "Записать и закрыть". Ха!!! Обманул! Окно закроется само после того как правила обмена загрузятся на предыдущем шаге.

Пункт №4

Тут все просто, нужно просто нажать ссылку "Включить регистрацию данных".

Вот именно в этот момент времени программа начинает регистрировать все изменения сделанные пользователями и регламентными заданиями в базе данных.

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

Пункт №5

Внимание!!! Не торопимся нажимать "Создание и обновление копии информационной базы данных".

Потом идем в MS SQL или что у вас там используется и делаем бэкап базы.

Пункт №6

Разворачиваем из бэкапа новую базу для обновления на новую версию конфигурации.

Я вот бы порекомендовал, наверное, на уровне сервера 1С отрубить регламентные задания в новой базе данных, если что, всегда можно вручную запустить регламентное задание "Отложенное обновление ИБ" и/или "Обновление через копию (отправка/получение)".

Тут тонкая грань выбора, или сидеть как дурак обрубать все регламентные задания в страхе, что возможно что-то будет срабатывать вопреки тому (а потом это все обратно нужно будет назад включать), что база данных находится в типа блокированном состоянии типа "Копия" же, и как бы регламенты обрублены, или вырубить все регламенты на уровне сервера и потом самому вручную рулить парой регламентных заданий "Отложенное обновление ИБ" и "Обновление через копию (отправка/получение)".

Пункт №7

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

Фирма 1С рекомендует отключить:

Пример операций, которые необходимо отключить:
•   получение почты;
•   рассылка отчетов;
•   синхронизация данных;

Риторический вопрос. Но нужно ли отключать это все, если регламенты в целом на сервере отрубить для базы данных как обозначено в Пункте №6? Практика показывает что как только база обновится, то начинают стартовать тучи регламентных заданий, да не все, но и не мало и они могут менять данные в новой базе, а ведь нам пока нужно данные получать только из старой базы.

Пункт №8

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

Пункт №9

Следуя описанию фирмы 1С, в старой базе теперь нажимаем ссылку "Создание и обновление копии информационной базы данных".

Но я бы не торопился наверное выполнять Пункты №9 и №10 пока не закончится, то что начнется в Пункте 11, так как старая база начнет истошно пытаться что-то выгружать, а это что-то еще никому не нужно, новая база еще вся сама в процессе обновления находится, ей бы переварить сначала, то что есть в самой базе данных и ей не до получения еще свежих порций данных.

Пункт №10

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

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

Пункт №11

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

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

Когда новая база данных даст возможность тыкать кнопки, то идем в "Администрирование / Обновление / Обновление программы" и там выбираем "Действие выполняется в обновляемой копии". Но как писал выше в Пункте №9 я бы не торопился это делать пока не будут обработаны основные данные, а уже потом только начинать приемку изменений из старой базы данных.

Там настраиваем транспорт обмена по аналогии с тем, что делали в старой базе данных ранее в Пункте №10.

Пункт №12

Ждем ночи, когда новая база обновится, сожрет данные из старой базы и тоже их переварит.

Пункт №13

Суеверия по поводу пункта 13 видимо... фирма 1С его опустила.

Пункт №14

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

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

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

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

Пункт №15

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

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

Для того, чтобы можно было следить, сколько объектов еще не обработано в обновляемой базе данных, то есть то, что находится в плане видов обмена "Обновление информационной базы" я запилил обработку "ЧислоОбъектовОтложенноеОбновление.epf". Применять её можно и не при обновлении через копию, а вообще при любом обновлении базы данных при переходе на новые релизы. Проверена на ERP 2.4.13-2.5.7.

Так же для того, чтобы можно было следить за картиной в плане видов обмена "Обновление через копию", я запилил обработку "ЧислоОбъектовОбновлениеЧерезКопию.epf". Имеет смысл ее применять только при обновлении через копию. Проверена на ERP 2.4.13-2.5.7.

UPD 2022-04-17
С выходом ERP 2.5.7.394 процесс обновления базы данных в общем случае стал быстрее, так как больше не обновляется регистр сведений распределения запасов как это было до этого во время отложенных обработчиков обновления базы. Фирма 1С сделала не обязательным использование автоматических мягких резервов, хотя они и продолжают существовать, но не являются режимом по умолчанию так сказать.
Но всегда есть но, у вас база данных может быть со своими нюансами и может быть вам все равно нужно обновление через копию.

Обновление через копию

+39 –

См. также

Обновление для КА 1.1, ЗУП 2.5, БУХ 2.0: НДС, ЕФС-1, Расчет страховых взносов, Мобилизация, Статистика, Электронные трудовые книжки, 2-НДФЛ, Регламентированная отчетность, Кадровый учет, Прослеживаемость импортных товаров

Зарплата Регламентированный учет и отчетность Кадровый учет Обновление 1С Бухгалтер Платформа 1С v8.3 Сложные периодические расчеты 1С:Комплексная автоматизация 1.х 1С:Бухгалтерия 2.0 1С:Зарплата и Управление Персоналом 2.5 Бухгалтерский учет Налоговый учет Управленческий учет Акцизы ЕНВД ЕСН Земельный налог ИП, ПБОЮЛ, КФХ Налог на имущество Налог на прибыль НДС НДФЛ ФОМС, ЕФС Транспортный налог УСН ПСН (патентная система налогообложения) Платные (руб)

Обновления для конфигураций: КА 1.1; ЗУП 2.5; БУХ 2.0; КА 1.1 Комплексная автоматизация торговли алкогольной продукцией; КА 1.1 Комплексный учет сельскохозяйственного предприятия

27900 руб.

01.04.2020 147099 649 360

235

Ошибка src\frntend\src\MergeModuleUtil.cpp или как не потерять недели работы при обновлении конфигурации

Обновление 1С Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

Расследование ошибки [fntend - src\frntend\src\MergeModuleUtil.cpp] при сравнении/объединении. Восстанавливаем утерянные недели работы.

13.11.2024 837 PerlAmutor 12

Сравнение, трехстороннее объединение и обновление с помощью WinMerge

Обновление 1С Программист Платформа 1С v8.3 Бесплатно (free)

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

21.10.2024 2661 mixaeel 18

Групповое изменение режима поддержки по подсистеме или файлу отчета сравнения конфигураций

Обновление 1С Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 Абонемент ($m)

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

1 стартмани

26.09.2024 501 3 milkers 2

Проблемы маркируемой продукции при переходе на версию УТ 11.5.19.63

Обновление 1С Пользователь Платформа 1С v8.3 1С:Управление торговлей 11 Россия Бесплатно (free)

Вышел новый релиз для УТ11 5.19.63. На копии базы было выполнено обновление и вылезли проблемы с номенклатурой, подлежащей маркировке. В публикации описаны проблемы, обнаруженные в копии базы конкретной организации.

24.09.2024 861 gull22 2

Чиним долгое сравнение конфигурации

Обновление 1С Программист Платформа 1С v8.3 Бесплатно (free)

Как исправить медленное сравнение конфигурации с файлом cf, сохраненным из хранилища.

17.09.2024 4369 vatkir 15

Обновление конфигураций с помощью Батника и Яндекс диска

Обновление 1С Пользователь Платформа 1С v8.3 1С:Управление торговлей 11 Абонемент ($m)

Упрощенное обновление конфигураций 1С (предпочтительно самописных) с помощью батника и Яндекс Диска (по публичной ссылке)

1 стартмани

22.08.2024 558 0 user1694357 0

Обновление тонких клиентов через Apache + PHP

Обновление 1С Системный администратор Россия Абонемент ($m)

На ИТС есть статья, в которой поверхностно описан процесс автоматического обновления тонких клиентов. В качестве примера, что логично, представлены методы конфигурации 1С. Но, в отличие от того же управления списками баз, для обновления не требуется хранить информацию, потому я решил переписать код на php, чтобы можно было отвязаться от 1С. Не работает для файловых баз, подключенных как File="ПутьКПапкеБазы"; (а жаль), для опубликованных файловых - работает.

1 стартмани

20.08.2024 681 MikeSh 10

Отзывы

28. PerlAmutor 155 14.04.22 18:18 Сейчас в теме

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

25. PerlAmutor 155 13.04.22 19:55 Сейчас в теме

(23) Кстати тут как-то вскользь сказано про ПланОбмена.ОбновлениеЧерезКопию , а тем временем это чуть ли не самое первое что надо настроить в рабочей базе, если там есть свои документы, константы, справочники, регистры. Надо модифицировать как минимум эти объекты:

ПланОбмена.ОбновлениеЧерезКопию
ПодпискаНаСобытие.ОбновлениеЧерезКопиюРегистрация
ПодпискаНаСобытие.ОбновлениеЧерезКопиюРегистрацияКонстанты
ПодпискаНаСобытие.ОбновлениеЧерезКопиюРегистрацияНабора

Иначе никакая регистрация своих объектов работать не будет.

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

29. PerlAmutor 155 15.04.22 17:15 Сейчас в теме

(27) Еще пара нюансов обновления.

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

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

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

А вот то, что Перечисление.СтавкаНДС стала в ERP 2.5 Справочник.СтавкаНДС и все реквизиты СтавкаНДС теперь с префиксом: УдалитьСтавкаНДС - действительно боль, т.к. такие документы у нас есть. Видимо придется уже дорабатывать после переноса, формирование движений, код, запросы и т.д.

Остальные комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. RustIG 1747 26.12.21 23:15 Сейчас в теме

жаль что у вас нет доступа к ИТС...
из вашей вводной части ничего не понял...
на ИТС в трех абзацах выражена вся идея:
https://its.1c.ru/db/erp25doc/bookmark/updatewithoutstop/UpdateWithoutStop

Напишу своими словами. По словам разработчиков ЕРП, из-за значительного времени на обработчики данных обновление ЕРП с 2.4 на 2.5 ресурсозатратное. Придумали использовать обновление через копию БД и дальнейший перевод пользователей в новую рабочую базу - таким образом получается без остановки работы пользователей: обновляем копию, переносим новые документы в копию, переводим пользователей в новую базу...

В общем, процедура предлагается для ЕРП-шников.

2. Brawler 458 26.12.21 23:59 Сейчас в теме

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

Процедура в скором времени станет обязательной и для КА 2.Х и УТ 11.Х уж поверьте...

3. RustIG 1747 27.12.21 00:58 Сейчас в теме

(2)

Описание того, как использовать "Обновление через копию" для крупных баз данных типа 1С:ERP.

Статья пока носит даже, больше так сказать, собирательный характер (общим вселенским разумом допишем её, если что не так), так как я сам пока не знаю на 100%, как правильно использовать этот механизм, убил немало времени на то, чтобы понять хоть что-то, но надеюсь, меня комментаторы ткнут носом в ошибки и я их исправлю в статье.

Предполагаю, что если вы это читаете, то, значит, вы уже обновили хотя бы один раз свою базу данных, например, с ERP 2.4.13 на ERP 2.5.7 и осознали, что это занимает ОЧЕНЬ много времени, потом вы произвели доработку-переработку всех своих изменений под 2.5.7 (кто-то кодит прям в основной конфигурации, а кто-то в расширениях, а кто-то и там, и там), все работает, ошибок нет, все готово и теперь нужно повторно обновлять базу, но уже живую/боевую.

Поехали!

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

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

Я для УТ 10.3 такую идею дважды-трижды-четырежды использовал - но у меня простые случаи - без 1сксих премудростей, в которых еще нужно разобраться как следует.... В УТ 10.3 из копии после проведения свертки или процедуры обновления с помощью ВыгрузкаЗагрузкаДанныхДляОднотипныхБаз перекачивал документы за период....

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

7. Brawler 458 30.12.21 14:55 Сейчас в теме

(3) 1С 100% не продуманно делают.
Они могли бы от релиза к релизу ERP 2.4 модифицировать данные в базе приближая их к 2.5, но нет они лупанули вообще все модификации разом и как итог получаем на уровне СУБД многочасовые реструктуризации данных, а потом бонусом еще более длительные отложенные обработчики обновления данных в базе. А до того как запустятся эти обработчики, неоправданно долго выполняется пометка в плане обмена "отложенного обновления" объектов к обработке... вроде бы как туда все последовательно загоняется, а не параллельно.

8. RustIG 1747 30.12.21 15:36 Сейчас в теме

(7) спасибо за информацию! да, судя по этому, плохи дела...

4. quazare 3800 27.12.21 04:34 Сейчас в теме

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

43. starik-2005 3087 20.05.22 10:07 Сейчас в теме

(4)

Правда правила обмена городил еще недели 3 до этого )

А потом еще месяца ТРИ перенагораживал. Плавали, знаем.

5. bulpi 217 27.12.21 17:30 Сейчас в теме

Тем, кто использует такие конфигурации - мне вас жаль. Тоскливая у вас жизнь.

6. Brawler 458 27.12.21 18:15 Сейчас в теме

(5) Грусть не то слово, по паре месяцев гробишь чтобы переделывать написанное, так чтобы потом базу обновить нужно еще и подвиги совершать...

9. triviumfan 97 10.01.22 19:19 Сейчас в теме

А сколько примерно будут выполняться обработчики отложенного обновления "для крупных баз данных типа 1С:ERP", если в наличии крутой сервак с жирным ЦП и крутыми дисками?

10. Brawler 458 10.01.22 20:43 Сейчас в теме

(9) Вот был опыт с 31-го на 01-ое обновление одной промышленной базы запускал на условно игровом ПК (i9 12900K, 128 GB DDR4 3600, SSD Samsung 980 PRO NVMe M.2 1000 ГБ)

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

База занимала ну что-то типа 365 гигов чисто данные.

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

-----------------------------
2021-12-31 16-48 запустил применение изменений
2021-12-31 20-55 процесс прервался по якобы причине того что якобы процесс завершил администратор
-----------------------------
2021-12-31 20-56 запустил снова
2022-01-01 00-44 снова обрыв связи... мля
-----------------------------
2022-01-01 00-48 запустил по новой после рестарта сервера
2022-01-01 04-34 окончательное принятие изменений основной конфы
-----------------------------

Ну где-то 4 часа реструкторизация базы идет (на ПК с 40 ядрами 3.2ГГц ксеон, с рейд массивом, это на этой же базе, но июнь, меньшего размера, шло часов 8)

-----------------------------
что-то еще поделал и продолжил дальше
2022-01-01 04-47 первый старт базы
2022-01-01 06-25 пометились объекты для обработки
-----------------------------
2022-01-01 06-29 запустил 20 потоков - 423 задачи всего
2022-01-01 06-42 готово 166 - добавил потоков до 24
где-то по времени еще докрутил до 28 потоков
.............
2022-01-01 19-22 готово 423 из 423 - (в июне на это ушло 4 дня на 40 ядрах + рейд)
-----------------------------
2022-01-01 19-23 бэкап жирной базы 625,5 гигов + лог 16,5 гига (база разжирела)
2022-01-01 19-28 закончился бэкап
-----------------------------
2022-01-01 19-29 - сжатие базы начало
2022-01-01 19-55 - сжатие базы завершено - вышло 430 гигов

!!! не забыть пересчитать итоги по бух регистру - 2022-01-01 17-30 пересчитал (как не странно, но часто слетают итоги при обновлении и поэтому не лишним будет их пересчитать руками отдельно)

При всем при этом процессор i9 странный, пришлось SQL заставить работать только на производительных ядрах (а иначе он переезжал на низко производительные ядра и сидел там все время, это я при других тестах видел и учел сразу), а 1С сервер в свободном плавании был, где хотел там и работал, но был один раз когда я его на низко производительные ядра спустил видя, что он работает слабо, а вот скуль пашет дай божа и поэтому я его переселил туда, где ресурсы простаивали

---

Еще ранее на тестах с 200 гиговой базой на проце i9

18.12.2021 14-50 начал обновление конфы
18.12.2021 16-13 применяю изменения
18.12.2021 19-09 перезапустил применение изменений, так как типа сеанс применения прерван админом и конфигуратор все откатил
18.12.2021 21-43 окончательное принятие изменений
18.12.2021 21-49 первый старт - прога помечает объекты к обработке в очередь
18.12.2021 23-11 обработка данных 24 потока 434 задачи
19.12.2021 00-55 вырубил камп
19.12.2021 10-15 продолжил
19.12.2021 10-42 включил 28 потоков
19.12.2021 17-59 готово 434 из 434

На этой же базе дальше пробовал обновлять, но уже на 2.5.7.279

19.12.2021 19-25 применяю изменения
19.12.2021 20-10 окончательное принятие изменений - 4 минуты
19.12.2021 20-21 первый старт - прога помечает объекты к обработке в очередь
19.12.2021 21-43 пошла обработка данных 206 задач
20.12.2021 01-37 готово 173 - прервал
20.12.2021 17-35 готово 173 - продолжил
21.12.2021 00-45 готово 198 - прервал
21.12.2021 17-40 готово 198 - продолжил
21.12.2021 22-58 прервал все к черту ибо сидеть еще кучу дней не охота, а там прогноз 3 дня

Прервал из-за этого
РегистрСведений.РаспределениеЗапасов
ОЧЕНЬ ДОЛГО ЗАПОЛНЯЕТСЯ регистр, процессор в полной нагрузке, скуль пашет как умалишенный

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

11. Brawler 458 10.01.22 20:45 Сейчас в теме

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

12. triviumfan 97 10.01.22 21:00 Сейчас в теме

(10)

запустил применение изменений

Как может принятие изменений быть 4 часа? Не могу себе представить. Это же лишь обновление конфы, которая 1-2 гига максимум.
Клиент 64-битный?
Сколько гигов ОЗУ было у сервера и скуля?

13. Brawler 458 10.01.22 21:05 Сейчас в теме

(12) база 365 гигов в начале была, в конце процесса уже сжатая 430 гигов занимала
винда, скуль, 1с - все 64 бит,
оперативки 128 гигов на всех - скулю отдано было 95 гигов

14. Brawler 458 10.01.22 21:09 Сейчас в теме

(12)

быть 4 часа?

Там я и про 8 часов писал и думаю 8 часов не предел еще!

15. triviumfan 97 10.01.22 22:43 Сейчас в теме

(14) а, я не так понял. "Принятие изменений" - это сохранение конфы + обновление + реструктуризация?
у скуля надеюсь параметр MDOP = 0?

16. Brawler 458 10.01.22 23:39 Сейчас в теме

(15)

"Принятие изменений"

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

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

Время обновления до сохранения конфы зависит сильно от того сняты ли замки у типовой конфы или нет. Даже пара снятых замочков выливается в часа полтора два (а бывало и по три часа делал) на все сравнения и объединения, а потом и сохранения.
Если все замки висят, то и за 10 минут, и за 30 может база обновиться, и сохраниться до применения.

(15)

MDOP = 0

Да, нулю равно было

17. Brawler 458 10.01.22 23:43 Сейчас в теме

(16) По MDOP = 0
С процессором i9 12900K это плохо работает.
Не знаю это выбор винды или самого скуля, но он часто уходил именно на 8 медленных ядер и там только на них и сидел словно нет вообще ядер быстрых, поэтому прям принудительно в настройках скуля приходилось отключать медленные ядра и тогда скуль переползал на быстрые ядра.
На серверных процах конечно такой проблемы не будет.

18. PerlAmutor 155 12.04.22 07:15 Сейчас в теме

Одной из проблем обновления базы через копию является ситуация, когда у вас есть готовый релиз ERP 2.5, вы разворачиваете копию базы, настраиваете правила конвертации и т.д. Несколько дней работают обработчики обновления нового релиза. При этом пользователи работают пока в старой базе. Но программистов 1С тоже можно отнести к пользователям. Это значит, что они продолжат вносить доработки в конфигурацию старой базы. В итоге, перед окончательным переходом надо будет дождаться окончания обработчиков обновления, закрыть вход, выгрузить конфигурацию рабочей, слить с новой версией ERP, снова сделать реструктуризацию, выгрузить повторно метаданные в XML файлы, снова переписать правила конвертации через КД3.1, снова зарегистрировать в обеих базах и только затем производить выгрузку. На это может уйти еще пара дней. Никакие уговоры руководства о запрете доработок до окончания обновления не помогут, т.к. если ошибка не дает выплатить людям зарплату, то обновление может подождать.

19. Brawler 458 12.04.22 10:05 Сейчас в теме

(18) если доработки будут такие что не затрагивают структуру метаданных то не страшно думаю, накладных расходов не увеличится

20. PerlAmutor 155 12.04.22 18:47 Сейчас в теме

(19) Я например до сих пор борюсь с обработчиками обновления ERP 2.5.7.383. Получилось так, что у регистра сведений ПараметрыАмортизацииОСБухгалтерскийУчет есть наш регистратор, документ. При попытке перенести данные из регистра УдалитьПараметрыАмортизацииОСБухгалтерскийУчет в новые регистры ПараметрыАмортизацииОСБУ, ПараметрыАмортизацииОСУУ и т.д., где нет этого регистратора - обработчики обрушиваются, т.к. в таблице Изменений по регистру в момент записи для плана обменов ОбновлениеИнформационнойБазы ссылка на документ превращается то ли в Неопределено, то ли в NULL.На релизе 2.4.14.164 обработчик создания ключей аналитики учета номенклатуры рушился лишь из-за того, что в табличной части документа ЭтапПроизводства2_2 была строка с незаполненной номенклатурой (пустая ссылка). В другом релизе обработчики обновления рушились из-за того, что Код Вида НДФЛ был неуникальным в справочнике. Просто потому, что определенного кода раньше не было и его добавили вручную. А когда в новом релизе появился, то уже все. И подобные проблемы у меня возникали постоянно при переходе с релиза на релиз.

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

21. Brawler 458 12.04.22 19:20 Сейчас в теме

(20) Какая-то слишком большая концентрация проблем у вас.
Как много ИТ специалистов базой рулит у вас?
Притормозить их деятельность нельзя на период обновления?

А качество обновлений да, фантастическое...

При переходе с 2.4.14.ХХХ на 2.5.7.ХХХ у нас например зациклились обновления состояний заказов из-за чего заказы все заблоченные были, установил насильно константу, что обновление закончилось, все разблокировалось. Благо последние этапы обновления были.
Заранее выгрузил список заказов.
Потом их тупо перепровел обработкой, и состояния встали по местам, но это частный случай.

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

22. PerlAmutor 155 12.04.22 19:26 Сейчас в теме

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

У меня еще вопрос насчет КД3.1 Вы принудительно выставляете режим "Записи" вместо "Проведения" для документов. Не получится ли так, что эти документы прилетят из другой базы с движениями, которые должны быть исправлены обработчиками обновления? Ведь при проведении в новой базе движения будут делаться с учетом новых регистров, новой логики запросов формирования движений. А если оставить режим записи, то этих движений просто не будет. Может в этом случае лучше планировать обновление на следующий релиз сразу же после закрытия месяца (делать копию и включать регистрацию новых документов только после закрытия).

23. Brawler 458 12.04.22 21:49 Сейчас в теме

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

24. PerlAmutor 155 13.04.22 06:13 Сейчас в теме

(23) Обновление через копию не умеет работать как обычный обмен? Например отработали все обработчики обновления, я чего-то там нажимаю и летит в новую базу порция данных, обрабатывается, в этот момент в старой базе плодятся новые документы. Я смотрю, что обработчики в новой базе закончились и докидывают новую порцию и так несколько раз пока все не закончится. Или там все за один раз только можно?

26. Brawler 458 13.04.22 20:52 Сейчас в теме

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

об этом я вроде выше говорил в статье

25. PerlAmutor 155 13.04.22 19:55 Сейчас в теме

27. Brawler 458 13.04.22 20:55 Сейчас в теме

(25) про ПланОбмена.ОбновлениеЧерезКопию я в статье заикался в контексте расширений баз данных, а вот про подписки на события нет))

>> Это наводит на определенные мысли о качестве обмена.
Ну как бы это норма для 1С...
Мне всегда "нравились" правила обмена межу 1С ДО и 1С ERP например, а тут такая же история видимо

28. PerlAmutor 155 14.04.22 18:18 Сейчас в теме

29. PerlAmutor 155 15.04.22 17:15 Сейчас в теме

30. Brawler 458 15.04.22 17:44 Сейчас в теме

(29) преобразование ставки ндс можно сделать в правилах обмена в КД 3.1

31. PerlAmutor 155 15.04.22 18:07 Сейчас в теме

(30) А есть пример как это делается? Я среди предопределенных элементов справочника СтавкиНДС не нашел ни одного элемента с которым можно связать. Похоже он заполняется при обновлении:

// см. ОбновлениеИнформационнойБазыБСП.ПриДобавленииОбработчиковОбновления
Процедура ПриДобавленииОбработчиковОбновления(Обработчики) Экспорт

	Обработчик = Обработчики.Добавить();
	Обработчик.Процедура = "Справочники.СтавкиНДС.СоздатьЭлементыПервоначальногоЗаполнения";
	Обработчик.Версия = "11.5.3.38";
	Обработчик.РежимВыполнения = "Монопольно";
	Обработчик.Идентификатор = Новый УникальныйИдентификатор("65d193c9-0397-421b-80ec-57fa152d9e0f");
	Обработчик.Комментарий = НСтр("ru = 'Заполнение справочника Ставки НДС';
									|en = 'Filling in the VAT Rates catalog'");
	
	Изменяемые = Новый Массив;
	Изменяемые.Добавить(Метаданные.Справочники.СтавкиНДС.ПолноеИмя());
	Обработчик.ИзменяемыеОбъекты = СтрСоединить(Изменяемые, ",");

КонецПроцедуры

Показать

И что делать с уже существующими объектами БД, которые не будут никогда перегружаться обменом, т.к. он только дельту шлет? Я про свои документы, справочники.

32. Brawler 458 15.04.22 18:41 Сейчас в теме

(31) Реквизит документа/табличной части СтавкаНДС в объекте источнике нужно связать с полем приемника УдалитьСтавкаНДС.
Вы его должны предусмотреть заранее подготавливая свое расширение, старое СтавкаНДС надо переименовать в УдалитьСтавкаНДС и создать радом новое СтавкаНДС с типом СправочникСсылка.СтавкиНДС.

Переносить значение СтавкаНДС в УдалитьСтавкаНДС нужно по правилу конвертации "Пер_СтавкиНДС", которое генерит КД 3.1 автоматически.

Потом в КД 3.1 в алгоритме "ПКО_Док_ВашТипДокументаИзРасширения_ПриЗагрузкеОбъекта" добавляем код который пропишет в новое поле СтавкаНДС преобразованное значение.

В общем модуле ОбщийМодуль.УчетНДСЛокализация есть для этого алгоритмы уже готовые

Используем их так

Для шапки документа

ТипНалогообложенияНДС = Неопределено; // Если у вас в документе есть этот реквизит, то возьмите из него значение

Объект.СтавкаНДС = УчетНДСЛокализация.СтавкаНДСПоПеречислению(Объект.УдалитьСтавкаНДС, ТипНалогообложенияНДС);

Для табличной части

МассивТЧ = ОбщегоНазначенияКлиентСервер.ЗначениеВМассиве("ИмяВашейТЧВДокументе");
                   
ОбъектИзменен = Ложь; // просто так...
                   
УчетНДСЛокализация.ЗаполнитьКолонкуТЧСтавкаНДС(Объект, МассивТЧ, ОбъектИзменен);

Когда окончательно перейдете на новый релиз, тогда можно будет смело удалить реквизит УдалитьСтавкаНДС

Уточните вопрос, я малость не понял его.

33. PerlAmutor 155 15.04.22 18:44 Сейчас в теме

(32)

Уточните вопрос, я малость не понял его

У меня не расширение, а живые собственные документы, со своими движениями. Они то конечно "поедут" сначала в копию базы, потом пользователи их будут добавлять. В итоге даже если я пропишу правила конвертации, то применятся они только к новым загруженным документам. А со старыми то как быть? Писать обработчики обновления?

34. Brawler 458 15.04.22 18:46 Сейчас в теме

(33) я думаю можно обойтись простой внешней обработкой которая их перепропишет

35. PerlAmutor 155 15.04.22 18:48 Сейчас в теме

(34) Т.е. тогда нет никакого смысла править конвертацию, надо писать обработку. Спасибо за примеры.

36. PerlAmutor 155 17.04.22 15:05 Сейчас в теме

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

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

Прикрепленные файлы:

missing_indexes.sql

39. Brawler 458 17.04.22 17:21 Сейчас в теме

(36) самая проблемная часть до последнего времени была, это обновление данных в регистре сведений распределения запасов, там например у нас формировалось регистрации изменений под 800 000+ событий (товар по которому нужно пересчет сделать, аля как задания в регистре заданий на пересчет распределений запасов), и вот эти события строчка за стройкой по очереди, не пачкой, производили расчет данных и это проходило очень долго. Очень "качественный" алгоритм обновления базы!

37. PerlAmutor 155 17.04.22 16:57 Сейчас в теме

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

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

Прикрепленные файлы:

38. Brawler 458 17.04.22 17:17 Сейчас в теме

(37) Сколько базы обновляю, не замечал чтобы версии новые создавались, все как правило наоборот, версии нет, а изменения есть, а потом дело юзерам шьют что они что-то меняли, а они не меняли, приходится на защиту вставить несправедливо обвиненных

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

40. PerlAmutor 155 17.04.22 18:27 Сейчас в теме

Я отключил версионирование для теста, больше в ЖР не вижу изменения регистра сведений Версии объектов при работе обработчиков обновления.

Прикрепленные файлы:

41. PerlAmutor 155 18.04.22 05:47 Сейчас в теме

Нашел ошибку в обработчике обновления РегистрБухгалтерии.Хозрасчетный (ERP 2.5.7.383), когда происходит ошибка.

Поле объекта не обнаружено (Ссылка)
{РегистрБухгалтерии.Хозрасчетный.МодульМенеджера(659)}:ОбновлениеИнформационнойБазыУТ.СообщитьОНеудачнойОбработке(ИнформацияОбОшибке(), Выборка.Ссылка);
{(1)}:РегистрыБухгалтерии.Хозрасчетный.ОбработатьДанныеДляПереходаНаНовуюВерсию(Параметры[0])
{ОбщийМодуль.ОбщегоНазначения.Модуль(5326)}:Выполнить ИмяМетода + "(" + ПараметрыСтрока + ")";
{ОбщийМодуль.ОбновлениеИнформационнойБазыСлужебный.Модуль(4250)}:ОбщегоНазначения.ВыполнитьМетодКонфигурации(КонтекстОбработчика.ИмяОбработчика, ПараметрыВызова);
{(1)}:ОбновлениеИнформационнойБазыСлужебный.ВыполнитьОтложенныйОбработчик(Параметры[0],Параметры[1])
{ОбщийМодуль.ОбщегоНазначения.Модуль(5326)}:Выполнить ИмяМетода + "(" + ПараметрыСтрока + ")";
{ОбщийМодуль.ДлительныеОперации.Модуль(1160)}:ОбщегоНазначения.ВыполнитьМетодКонфигурации(ИмяПроцедуры, ПараметрыВызова);
{ОбщийМодуль.ДлительныеОперации.Модуль(1150)}:ВызватьПроцедуру(ВсеПараметры.ИмяПроцедуры, ВсеПараметры.ПараметрыПроцедуры);

Показать

Вместо Выборка.Ссылка надо поменять на Выборка.Регистратор.

42. PerlAmutor 155 05.05.22 06:26 Сейчас в теме

В общем наша база обновлялась с 2.4.14 на 2.5.7 - 12 дней на рабочем сервере. И прошел уже почти месяц как она обновляется на домашнем компьютере, где все упирается в медленные HDD диски. Размер базы около 300Гб.

44. energosf_vl 13.04.23 08:43 Сейчас в теме

Не понятно, откуда на первом этапе должна взяться обновленная конфигурация приемника с нужным релизом, если копию до нужного релиза еще не то что не обновляли, но даже не делали. Без конфигурации-приемника нужного релиза не сделать правила обмена, без загруженных правил обмена не включить регистрацию измененных объектов в базе-источнике. Без регистрации потеряется дельта, которая возникнет в базе-источнике, пока будет обновляться до нужного релиза копия и будут готовиться правила обмена.
Или подразумевается, что пустая база-источник сначала обновляется до нужного релиза и с нее снимается слепок конфигурации для правил?
Речь, естественно, идет про измененные конфигурации, с типовыми то понятно, где релиз приемника взять.

45. Brawler 458 13.04.23 09:40 Сейчас в теме

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

46. energosf_vl 14.04.23 08:05 Сейчас в теме

(45) Ну, к слову сказать, в инструкции об этом ни слова.
Я в целом говорю про сам процесс, на мой взгляд, логичнее было бы, если возможность включения регистрации измененных данных была доступна до момента создания и загрузки правил обмена, т.е. включил обновление через копию, включил регистрацию, сделал копию и с ней работаешь дальше, сколько нужно, обновляешь до нужного релиза, правила готовишь и т.д. А дельта данных в рабочей базе уже собирается. Плюс не потребуется цепочка обновлений конфигурации до нужного релиза только ради изготовления правил обмена.

47. Brawler 458 14.04.23 08:20 Сейчас в теме

(46) так вы там всеми своими подготовками лет 10 заниматься будете, еще в процессе этих увлекательных процедур может потребуется десяток релизов попроще накатить на базу. Как вы себе представляете перенос накопленных данных за 10 лет пока вы там cf с исправлениями готовите или cfe тоесть расширения?
Верх глупости врубать регистрацию изменений и сидеть корпеть исправления делать.
Исправления надо делать заблаговременно до процедуры непосредственного обновления, где вы врубаете регистрацию изменений и по шустрому обновляете копию и переносите в нее все измененное за время обновления. Минимизировать нужно объем измененных данных, а то можно и никогда не перейти, придется сидеть и наблюдать как данные перекачиваются и перекачиваются, возможные ошибки перекачки плодятся и плодятся.