1с как обновить конфигурацию без реструктуризации
Обновлено: 07.07.2024
При установке обновлений на базу с конфигурацией, снятой с поддержки и доработанной, выполняется фактически обновление двух конфигураций: обновление конфигурации поставщика (обновление типовой конфигурации, без изменений, до текущего релиза), и обновление основной конфигурации.
Для обновления конфигурации поставщика используется файл cf типовой конфигурации, не снятой с поддержки. Для обновления основной конфигурации используется предварительно подготовленный файл cf (берется типовая конфигурация, в нее вносятся сделанные изменения, и конфигурация выгружается в файл cf)
Собственно процесс обновления выполняется в 2 этапа: обновление конфигурации поставщика, и обновление основной конфигурации. Последовательность выполнения этапов не принципиальна.
Для чего нужны 2 конфигурации в 1 флаконе? Такое сочетание конфигураций базы удобно использовать для получения перечня изменений в типовой конфигурации. В основной конфигурации содержится конфигурация с изменениями, в конфигурации поставщика – типовая. При помощи встроенного в платформу механизма сравнения конфигураций (в данном случае основной и поставщика), можно получить наглядное представление о том что было изменено в конфигурации в сравнении с типовой. Единственное условие для комфортной работы при сравнении – это поддержание одинаковых версий релизов обеих конфигураций. Для этого нужны 2 файла cf – один для основной, другой – для конфигурации поставщика.
Представим себе, что оба файла cf у нас есть (по подготовке cf с изменениями — отдельно) Назовем их, например, «Типовая_2_0_49_8.cf» и «Обновление_2_0_49_8.cf» Соответственно, первый файл – это обновление для конфигурации поставщика, второй – для основной конфигурации.
Начнем с обновления конфигурации поставщика.
В режиме Конфигуратор, идем в меню Конфигурация – Поддержка – Обновить конфигурацию. В получившемся диалоге выбираем переключатель «Выбор файла обновления», и говорим «Далее»
Далее нам предлагается указать файл обновления:
Тут все знакомо. Указываем файл «Типовая_2_0_49_8.cf», и нажимаем Готово
Со всем, что будет появляться дальше – соглашаться)))
После утрясения всех вопросов, платформа начнет загрузку конфигурации для сравнения. Это занимает некоторое время…
По окончании загрузки получаем следующее окно:
Здесь нам показывают различия между тем что у нас уже есть, и тем, что мы пытаемся загрузить. В первой колонке – различия между новой конфигурацией и конфигурацией базы данных (основной), во второй – различия между текущей конфигурацией поставщика, и загружаемой конфигурацией.
Так как нам нужно обновлять только конфигурацию поставщика, а основную пока не трогать, снимаем все галки в левой колонке (если снять самую верхнюю, все остальные ниже снимутся самостоятельно)
Нажимаем «Выполнить», ждем некоторое время…
В процессе загрузки может появиться следующее окно:
Это относится к блокировке объектов базы. Если все переключатели будут установлены в режим «Объект не редактируется», внесение изменений в конфигурацию будет невозможно без предварительного снятия конфигурации с поддержки (объекты на поддержке, снятые с поддержки и редактируемые с сохранением поддержки – отдельная тема) В большинстве случаев настройка правил поддержки выполняется так, как указано на снимке
Идем в меню Файл – Сохранить (платформа сохранит сделанные изменения), и затем в меню Конфигурация – Обновить конфигурацию базы данных. Процесс займет некоторое время, и будет требовать принятия изменений в течение реорганизации.
На этом первый этап закончен.
Обновление основной конфигурации.
В режиме Конфигуратор идем в меню Конфигурация – Сравнить, объединить с конфигурацией из файла. Сразу же получаем окно для выбора файла, в котором указываем наш файл для обновления основной конфигурации «Обновление_2_0_49_8.cf» Платформа сразу же начинает сравнение конфигураций.
Так как наш файл «Обновление_2_0_49_8.cf» содержит уже обновленную конфигурацию, с учетом всех изменений, то все галки в левой колонке теперь оставляем на месте.
После нажатия кнопки «Выполнить», будет выполнено объединение конфигураций (аналогично первому этапу)
Идем в меню Файл – Сохранить, затем Конфигурация – Обновить конфигурацию базы данных
После выполнения всех действий по обновлению, открываем базу в режиме Предприятия, и подтверждаем легальность получения обновлений
На самом деле, если изменения в конфигурации минимальны, и заранее известны, можно обойтись только одним этапом – обновлением конфигурации поставщика. При этом в левой колонке нужно снять галки с тех объектов, которые были изменены по отношению к типовой. Однако эта методика применима только в том случае, когда не требуется внесения изменений в формы и/или сравнения больших блоков кода. Новая типовая конфигурация будет наложена на текущую, за исключением тех объектов, которые мы снимем с объединения.
Методика обновления – универсальна, подходит не только для конфигураций «БухгалтерияПредприятия», но и для Комплексной, и для ЗУП, и для прочих…
В свое время не смог найти краткой инструкции по обновлению, поэтому пишу эту статью.
Помните анекдот про молодых охотников и медведя. Так вот – главное не бояться.
Статья предназначена для самых начинающих, коими все когда-то были.
Итак, у нас должна быть копия рабочей базы с идентичной конфигурацией, на которой мы и будем выполнять обновление с последующей загрузкой cf-файла в рабочую базу.
Выгружаем конфигурацию рабочей базы в cf-файл.
Сравниваем выгруженную рабочую конфигурацию с конфигурацией нашей копии – они должны быть идентичны. Если нет, то можем снять конфигурацию копии с поддержки и полностью загрузить конфигурацию из файла.
Подготавливаем файл обновления (скачиваем с сайта 1С и устанавливаем какую-нибудь свою папку).
В копии нажимаем: Конфигурация – Поддержка – Обновить конфигурацию.
Устанавливаем переключатель на «Выбор файла обновления» и указываем наш файл обновления. Нажимаем «Готово». Ждем, когда выполнится сравнение.
После того как появилось окно сравнения, первым делом снимаем галочку с корневого элемента конфигурации.
Потом заходим в настройки и ставим галочку разрешить удаление – это важно иначе можем получить ошибки после обновления
Потом заходим в фильтр и устанавливаем «Показывать отличия новой конфигурации поставщика от старой конфигурации поставщика».
При этом фильтре устанавливаем галку на корневом элементе конфигурации – у нас выберутся все необходимые объекты.
Заходим опять в фильтр, оставляем «Показывать отличия новой конфигурации поставщика от старой конфигурации поставщика», и устанавливаем галку «Показывать только дважды измененные свойства» - это те объекты поставщика, в которые вносили изменения мы и есть изменения в новой конфигурации поставщика – вот с ними нам и нужно разбираться.
Применяем фильтр – ну вот объектов значительно меньше и уже не так страшно (помним – главное не бояться).
У ролей и тех объектов, у которых изменен состав – устанавливаем «объединить с приоритетом новой конфигурации поставщика».
У модулей в колонке «Режим объединения и порядок подчинения» нажимаем «Открыть».
Анализируем процедуры и функции модуля и по каждой принимаем решение (см галочки и режим объединения). Зачастую бывает достаточно установки или снятия необходимых галочек - галочка снимается, если в процедуре только наши изменения (для этого и нужны комментарии) или оставляется, если в процедуре только изменения поставщика.
Если в новой конфигурации поставщика отсутствует типовая процедура (не наша) то нужно установить галочку (режим объединения – Удалить).
Если есть изменения и наши и поставщика – то нужно режим объединения установить «объединить». Записать в каком модуле, в какой процедуре, какие изменения и после объединения откорректировать соответствующий модуль. Т.е. например, ставим «объединить с приоритетом новой конфигурации», а потом снимаем комментарии с наших изменений (программа закомментирует наши изменения).
Самое неприятное – изменение форм. Для того чтобы понять что менялась сама форма а не просто модуль, делаем следующее: встаем на необходимый объект, нажимаем правую кнопку мыши и выбираем «Отчет о сравнении объектов».
Далее делаем настройку как показано на скриншоте. И анализируем изменения.
Возможно, достаточно будет объединить форму с приоритетом новой конфигурации поставщика или вовсе взять из файла, если модуль формы не менялся.
После всех корректировок нажимаем «Выполнить», игнорируем страшные предупреждения программы если они появляются и не соглашаемся на предложения включить дополнительные объекты в объединение (мы же до этого все делали правильно правда?) Делаем в итоговой конфигурации необходимые изменения. Сохраняем конфигурацию и обновляем конфигурацию базы данных. Запускаем 1С Предприятие и проводим обновление. Проверяем, что ключевые документы открываются и проводятся без ошибок. Сохраняем конфигурацию в файл.
Далее делаем копию рабочей базы. Копию нужно делать средствами SQL если база серверная или копированием соответствующей папки если файловая. Файл dt не подойдет. То, что вы выгрузите этот файл, еще не гарантия что вам удастся его загрузить, к тому же выгрузка/загрузка dt на больших базах занимает много времени.
Заходим в конфигуратор рабочей базы и через сравнение и объединение проверяем с файлом конфигурации, который мы выгружали из этой базы – конфигурации должны быть идентичны. Снимаем конфигурацию с поддержки (вы же помните – главное не бояться). Конфигурация – Поддержка – Настройка поддержки – Снять с поддержки. Сохраняем. Загружаем конфигурацию из файла (Конфигурация – Загрузить конфигурацию из файла – Выбираем наш файл конфигурации, который мы выгрузили из копии).
После загрузки сохраняем конфигурацию, обновляем информационную базу. Проводим обновление в режиме предприятия. Ждем отзывов от благодарных пользователей.
Так можно накатить сразу несколько релизов (на копии мы последовательно накатываем релизы с обновлением в режиме предприятия), а на рабочую базу накатываем общий получившийся в результате этого фай cf.
(19) просто некоторым не нравится такой способ - накатить загрузкой из файла.
Но накатывание любым другим способом и этим тоже просто сформирует в конфигураторе "Текущую конфигурацию" базы - она будет полностью готовая. Затем она просто применяется к основной. И применение к основной выполняет всегда одни и те же действия, одинаковые для всех способов и источников получения Текущей.
Ибо гуиды в поставке не совпадали с гуидами в базе
Но это было достаточно давно, сейчас вроде как за этим следят, но шанс того что что то пойдёт не так - он есть и отличен от нуля
(26) конечно, в полной поставке есть cf его можно выгрузить в xml и посмотреть
(27) Я как-то пытался. Просто не увидел их там. Хотя искал не гуиды. Может просто не обратил на них внимания.
(24) Это когда происхождение базы, на которой готовилось, отличается от происхождения базы, к которой применяется обновление.
(29) Спасибо! Не знаю как бы догадался заглянуть именно в такие файлы, чтоб их увидеть.
Мда. но ведь в самом деле, не будешь же каждый раз проверять, что при получении хз откуда готового ЦФ у этих идентификаторов значения не изменятся?
(31) Зачем проверять? Просто никогда не используй сравнение для переноса изменений(особенно при добавлении метаданных) в рабочую базу. Только загрузка цф.
Ну и копипаста метаданных между конфигурациями из той же серии, бомбу заложить.
(32) и вот к чему твой сарказм?
У тебя по РИБ базы никогда не глючили?
А ведь такая же точно херня - если прилетает измененный объект метаданных, то он тупо вкорячивается в текущую без каких-либо сравнений.
Альтернативные способы дубли предопределенных обязательно создадут.
(32) +100 однозначно правильный подход, но только при условии, что все источники cf подконтрольны
кстати при обновлении через "сравнить объединить" есть флажок "заменять внутренние идентификаторы", это позволяет накатывать только часть объектов но в режиме полной идентичности
(36) ну да, это тоже интересный режим - рискованный, скажем так
(33) Это не сарказм, а практика. Если конфигурация находится под твоим контролем, то проблемам просто неоткуда взяться. Если обнова тебе пришла извне, то проблемы ты увидишь при реструктуризации (без просмотра ИД метаданных).
То есть разбираться с кривыми ИД приходится только в одном случае: кривообновленная конфа полученная в наследство. Но даже в такой ситуации проще потерять данные и перенести их из копии чем сопоставлять ИД метаданных. Мегабаз с кривыми обновлениями по идее быть не должно.
(39) архивы и бэкапы - это не роскошь, а суровая необходимость.
Никогда такого не было и вот опять.
А ведь только пукнуть хотел.
Ворчал себе под нос мужик, застирывая джинсы
(39) С причинами разобрался?
Перенос данных между двумя базами с одинаковыми конфигурациями (без учета ИД метаданных) задача тривиальная - ВыгрузкаЗагрукаXML. Проблема может быть с объемом и скоростью, но редко:
1. как правило ломаются свежедобавленные метаданные (объем данных небольшой)
2. большие базы не должны жить в кривых руках
(41) >>>Перенос данных между двумя базами с одинаковыми конфигурациями (без учета ИД метаданных) задача тривиальная - ВыгрузкаЗагрукаXML.
банально только попробуй создать пустую базу, в ней создастся куча предопределеннх данных, а при загрузке они задвоятся. а с функциональными опциями не пробовал переносить? пока опция не включена в базе нет физической таблицы :)
(41) кстати причина была в кривых начислениях удержаниях (точно не помню), в одном почему-то использовался формат datetime2 вместо datetime (хоть они и совместимые, но не очень) и еще какая кто засада с идентификаторами в предопределенных групах верхнего уровня была,
я писал в 1с, они ошибку приняли и отнесли ее на платформу.
(43) Предопределенные конечно чистятся при необходимости.
"пока опция не включена в базе нет физической таблицы" а вот это бред чистой воды
(45) не бред, можешь посмотреть в SQL.
разумеется при отключении опции уже созданные таблицы не удаляются
(46) Ты серьезно? Я константу переключил и в SQL пошли создаваться? .. в режиме предприятия при разделенном доступе.
Фантастика, может конечно с развитием расширений и придем к такому когда-нибудь с КОРП лицензиями.
Сейчас без использования расширений таблицы SQL создаются исключительно при реструктуризации
Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.
Мы разработали новый механизм реструктуризации базы данных, который позволяет ускорить обновление конфигурации в среднем в 3-4 раза, а в отдельных случаях на порядки. Ускорение достигается за счёт минимизации манипуляций над данными и максимального их переноса на уровень системы управления базой данных (СУБД).
Что такое реструктуризация?
Реструктуризация это изменение структуры и состава таблиц базы данных, и перенос имеющихся данных в изменённые таблицы. Обычно реструктуризация выполняется в тот момент, когда вы нажимаете Обновить конфигурацию базы данных в Конфигураторе. Но выполняется она не каждый раз.
Реструктуризация выполняется тогда, когда изменения конфигурации требуют появления новых колонок или таблиц в базе, или когда меняется тип существующей колонки. Например, вы добавили реквизит к справочнику, добавили документ, или изменили тип имеющегося реквизита с Число на Строка. В этих случаях потребуется реструктуризация.
Если рассматривать реструктуризацию с точки зрения манипулирования данными, то существует база данных и схема данных, которая соответствует конфигурации базы данных. После того, как вы обновляете конфигурацию базы данных, создаются новые структуры данных, в которые переносятся старые данные.
«Традиционная» реструктуризация
В процессе реструктуризации последовательно анализируются все объекты конфигурации. Не углубляясь в подробности можно сказать, что для каждого объекта выполняется:
- Анализ его изменений;
- Создание новых таблиц в базе данных, которые соответствуют новой структуре объекта;
- Перенос данных.
Из этих трёх шагов перенос данных занимает наибольшее количество времени. При этом сами операции переноса данных могут быть простыми и сложными.
Например, к простым и быстрым операциям относятся те, которые вызваны добавлением или удалением столбцов таблицы. В этом случае отдельным запросом создаётся новая таблица (с изменённой структурой) и данные переносятся в неё.
Все остальные операции являются сложными, могут занимать длительное время, и для их выполнения требуется участие Конфигуратора (или серверной части платформы, если обновление выполняется на сервере). Потому что процесс переноса данных может сопровождаться различными вспомогательными действиями, обусловленными спецификой 1С:Предприятия.
Например, может потребоваться удаление ссылок на несуществующие объекты, изменение предопределённых данных, предварительная фильтрация данных (для удаления движений, соответствующих удаляемым регистраторам), проверка уникальности номеров и кодов, проверка количества уровней вложенности справочника и корректности его иерархии, и другие.
Новый механизм реструктуризации
Главное изменение заключается в том, что оптимизация реструктуризации достигнута не за счёт локальных изменений «традиционного» механизма, а за счёт создания полностью нового механизма реструктуризации.
Это непростая и трудоёмкая задача, потому что механизм реструктуризации должен обеспечивать транзакционность изменений, то есть надежность и целостность базы данных во всех случаях. Механизм должен быть готов к тому, что процесс реструктуризации может прерваться в любой момент (в результате сбоя, например), и при этом система должна остаться в консистентном состоянии. То есть либо в виде старой версии, либо в виде новой версии. Старый механизм для этого создавал новые версии изменённых таблиц, и заполнял их. А потом подменял все старые версии на новые.
Новый механизм тоже обеспечивает транзакционность, но более сложным способом.
Кроме этого новый механизм основан на ряде идей, которые позволили получить значительное ускорение:
- Максимальное количество операций делегируется на уровень СУБД, потому что это наиболее близкая к данным часть, и она имеет большие возможности изменения данных.
- Обрабатываются только те таблицы СУБД, в которых изменения конфигурации могут вызвать изменение данных. В «традиционном» механизме это было не всегда так. Например, при изменении реквизита табличной части документа копировались данные и основной таблицы, и всех табличных частей документа.
- Табличные части реструктуризируются отдельно. При этом возможно отдельное «пореквизитное» их изменение. Например, если вы добавили реквизит к табличной части, то к таблице просто добавляется новый столбец, без модификации основной таблицы.
На основе этих идей мы достигли максимальной оптимизации на тех изменениях конфигурации, которые приводят к следующим операциям с данными:
- Добавление или удаление столбцов таблиц. Эти операции проводятся теперь на текущих таблицах (раньше создавались новые таблицы и в них переносились данные). Необходимость добавления или удаления столбцов возникает, например, при добавлении или удалении реквизитов, при изменении некоторых свойств объекта конфигурации (иерархия справочника и столбец _ParentID) и др.
- Добавление или удаление индексов. Просто создаётся новый индекс, без создания новых таблиц и переноса данных. Эти операции выполняются, если вы установили индексирование у реквизита, например.
- Изменение существующих индексов. Также выполняется без создания таблиц и переноса данных. Например, кластерный индекс регистра сведений меняется тогда, когда вы добавляете измерение.
В других операциях перенос данных требуется как и раньше, но практически всегда (в большей части операций) он осуществляется на уровне СУБД. Данные переносятся единым запросом. Это может быть INSERT для новых таблиц, или UPDATE существующих таблиц.
Конечно, существуют такие изменения, которые всё равно проходят обработку на сервере с выгрузкой данных построчно. Например, преобразование строки в число, или в дату. Такие операции нецелесообразно делать на уровне СУБД, к тому же они довольно редко встречаются. Но наиболее частые изменения проводятся всё же на уровне СУБД, одним запросом на одну таблицу.
В среднем ускорение достигает 4 раз. Это, конечно, зависит от конкретной конфигурации, от конкретных изменений, и даже конкретных данных. В отдельных случаях ускорение может быть до 20 раз. Такое возможно, например, при удалении реквизита в большой таблице, или если изменения затрагивают маленькие таблицы, но сам объект при этом является довольно большим.
Помимо ускорения есть и другой положительный момент. Во многих случаях не перестраиваются индексы. Это позволяет сохранить их актуальность, сохранить статистику, сократить место, требуемое для реструктуризации.
Мы провели несколько сравнительных экспериментов на реальных информационных базах, и получили следующие результаты:
- Добавление реквизитов к документам и измерений к регистрам сведений. База 400 Гб. Новый механизм позволяет ускорить реструктуризацию с 2 часов до 15 минут.
- Изменение режима совместимости с 8.2.19 на 8.3.6. База 6 Тб. Ускорение с 5 дней до 12 часов.
Особенности текущей реализации
Новый механизм реструктуризации мы планируем включить в версию 8.3.11 в статусе бета. Он реализован только на сервере, причём на сервере должна быть установлена Java 8.
Чтобы использовать новый механизм реструктуризации, вы можете запустить Конфигуратор в пакетном режиме. Кроме этого в файле conf.cfg вы также можете указать необходимость использования нового механизма. Тогда новая реструктуризация будет выполняться при нажатии Конфигурация – Конфигурация базы данных – Обновить конфигурацию базы данных на сервере. Если никаких специальных действий не предпринимать (просто установить новую платформу), то стандартно будет использоваться старый механизм.
Пока поддерживаются только две СУБД: MS SQL Server и PostgreSQL.
На текущий момент мы оптимизировали реструктуризацию не всех объектов конфигурации, а только основных:
- Планов обмена,
- Справочников,
- Документов,
- Журналов документов,
- Планов видов характеристик,
- Планов счетов,
- Регистров сведений,
- Регистров накопления,
- Регистров бухгалтерии.
Для перечисленных объектов (кроме регистров) оптимизированы любые их изменения. Для регистров мы оптимизировали реструктуризацию движений и реструктуризацию таблиц регистрации изменений. Операции пересчёта итогов и пересчёта срезов для регистра сведений мы пока не оптимизировали. Однако, несмотря на это, использование нового механизма уже даёт существенное ускорение всего обновления регистров в целом.
Мы рассматриваем возможность увеличения охвата операций и расширения состава объектов конфигурации, реструктуризация которых оптимизирована в новом механизме.
Читайте также: