1с версии объектов очистить
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
1. Если при изменении структуры метаданных конфигурации планируется удалить объект метаданных (реквизит, измерение, ресурс и пр.), связанный с записями информационной базы, то необходимо принять решение об удалении или переносе данных этого объекта в новые структуры. При переносе данных в другие объекты рекомендуется придерживаться следующих правил.
1.1. Не удалять из конфигурации устаревшие объекты метаданных и реквизиты безвозвратно, а пометить их как устаревшие, добавив к их именам префикс "Удалить" (англ. "Obsolete" ). Например: реквизит "ОсновнойДоговор" (англ. "MainContract" ) должен быть переименован в "УдалитьОсновнойДоговор" (англ. "ObsoleteMainContract" ).
В синоним устаревшего объекта (реквизита) рекомендуется добавлять префикс "(не используется)" (англ. "(not used)" ), например: "(не используется) Основной договор" (англ. "(not used) Main contract" ). Если же устарел стандартный реквизит, то префикс "(не используется)" также добавляется в его синоним.
1.2. После изменения структуры метаданных следует обеспечить перенос данных из устаревших реквизитов в новую структуру метаданных конфигурации.
1.3. Если удаляемый объект метаданных является документом – регистратором движений, а соответствующие регистры с движениями остаются в составе конфигурации, то необходимо обратить внимание на необходимость сохранения движений. Для сохранения движений документов – устаревших объектов метаданных, рекомендуется:
- Запретить генерацию движений при проведении документов этого вида.
- Запретить снятие пометки удаления для документов этого вида.
- Во всех существующих движениях документов этого вида изменить регистратор на один или несколько замещающих документов-регистраторов: существующих универсальных или специально разработанных. Например "Перенос данных", "Операция".
- Пометить все документы этого вида на удаление.
1.4. Произвести замену во всей конфигурации обращений к устаревшим реквизитам на обращение к новым данным, поскольку использование устаревших объектов и их реквизитов после изменения структуры метаданных методически неверно. В частности, исключить устаревшие объекты метаданных из всех ролей (кроме ролей ПолныеПрава и АдминистраторСистемы ), подписок на события и т.п., а также удалить у них код, формы, макеты, команды и другие элементы, ставшие избыточными.
1.5. При сортировке устаревших объектов метаданных и реквизитов в дереве метаданных следует придерживаться общих требований к конфигурации.
1.6. Также рекомендуется выполнить очистку устаревших данных с тем, чтобы они не влияли на размер базы и не потребляли ресурсы (при резервном копировании, реструктуризации и других операциях).
В случае сложных (ошибкоемких) алгоритмов переноса данных, такую очистку целесообразно проводить не сразу, а через один или несколько релизов. Тем самым, остается возможность выпуска внепланового релиза для устранения последствий некорректной работы алгоритмов переноса.
2. Необходимость в переносе данных также может возникнуть при пересмотре структуры измерений регистров. Следует создать новый регистр с правильной структурой, а старый отметить как устаревший и перенести записи из старого регистра в новый в тех случаях, когда измерение регистра сведений становится не актуальным: удаляется, либо изменяется его тип, либо у измерения составного типа уменьшается состав типов.
При этом создать новый регистр не требуется, если в регистр добавляется новое измерение или у измерения составного типа расширяется состав типов.
3. Безвозвратно удалять устаревшие объекты метаданных и реквизиты, помеченные префиксом "Удалить" (англ. "Obsolete" ), следует при выпуске очередных версий конфигурации в том случае, если соблюдается одно из условий:
- Переход со "старой" версии конфигурации на новые версии всегда выполняется пользователями последовательно, "через" версию с реализованным переносом данных из "устаревших" объектов метаданных и реквизитов. Например: если в конфигурации версии 1.1 реквизит "ОсновнойДоговор" был помечен как устаревший, то переход с версии 1.0 на версию 2.0 всегда выполняется только последовательно: сначала на версию 1.1 (в которой происходит обработка устаревших данных), а затем на 2.0 (в которой устаревшие данные могут быть удалены безвозвратно). Непосредственный переход с версии 1.0 на 2.0 технически невозможен (запрещен).
- Вероятность того, что "старой" версией конфигурации еще пользуются, стала нулевой или пренебрежимо малой.
При этом может потребоваться выпустить промежуточный релиз, в котором обеспечить очистку устаревших данных – см. п.1.6. В противном случае, может завершиться ошибкой реструктуризация регистров, в измерениях которых остаются ссылки на устаревшие данные.
В программе 1С практически ни один объект нельзя сразу физически удалить. Данная возможность настраивается в ролях (права «удаление» и «интерактивное удаление»). Обычно разработчик не разрешает выполнение таких действий во избежание плачевных последствий в дальнейшем.
Пометка на удаление означает неактуальность объекта для пользователя. При установке пометки на документ, автоматически отменяется его проведение.
Далее будет подробно рассмотрено, как можно не только пометить объект на удаление в 1С 8.3, но и физически удалить помеченный объект. Этот принцип применяется во всех конфигурациях 1С.
Пример удаления элемента справочника Номенклатура
В нашем примере мы будем удалять элемент справочника «Номенклатура», но процесс удаления документа или любого другого объекта ничем не отличается от приведенной инструкции.
Установим пометку на удаление непосредственно из формы списка данного справочника. Для этого выделим нужную нам позицию и нажмем на клавиатуре клавишу Del (либо воспользовавшись контекстным меню).
Программа задаст нам вопрос о необходимости (либо снятии) пометки на удаление. Ответим «Да».
После этого у выбранного нами элемента справочника появится знак . Напоминаем, что если у объекта конфигурации доступны права на удаление, либо интерактивное удаление, тогда при помощи комбинации Shift+Del вы сразу сможете удалить его физически.
Теперь можно приступить к непосредственному удалению нашего объекта справочника. Если у вас не будет доступен данный функционал, значит, вы не имеете соответствующих на него прав.
Выберите в меню «Администрирование» пункт «Удаление помеченных объектов».
Так же данный функционал доступен в меню «Все функции».
В открывшемся окне программа предложит вам выбрать, хотите ли вы удалить все помеченные на удаление объекты или только некоторые. В нашем примере мы будем удалять только номенклатуру «Доска обрезная 50*250*300».
После того, как вы нажмете «Далее», выведутся все помеченные на удаление объекты. Отметим флагом только нашу номенклатурную позицию «Доска обрезная 50*250*300» и нажмем «Удалить».
Некоторое время система будет вычислять, не ссылаются ли другие объекты информационной базы на нашу доску. В результате программа выдала нам уведомление о том, что удаление невозможно.
Нажмем на кнопку «Далее» для просмотра тех объектов, из-за которых удаление невозможно.
Чтобы наша номенклатура все-таки удалилась, необходимо пометить на удаления все объекты в таблице справа. Еще одним вариант – везде заменить наш объект на другой.
С простановкой пометки на удаления у связанных объектов у вас не должно возникнуть проблем, поэтому мы выберем замену.
Нажмите на кнопку «Заменить…».
Выберем ту номенклатурную позицию, на которую будет произведена замена во всех связанных объектах. После этого вам снова будет доступно окно для повторного удаления. На этот раз все прошло успешно, о чем нас уведомила программа.
Автоматическое удаление помеченных объектов по расписанию
В более новых версиях программы 1С (начиная с 8.3) разработчики добавили очень удобную возможность автоматического удаления помеченных объектов по расписанию. Давайте рассмотрим, как сделать данную настройку.
В открывшейся форме перейдите в раздел «Регламентные операции» и установите флаг в пункте «Автоматически удалять помеченные объекты по расписанию». После этого для вас станет активной гиперссылка «Настроить расписание». Перейдите по ней.
Перед вами откроется стандартная форма настройки расписания. При необходимости можете изменить установленные по умолчанию значения, но так чтобы время запуска данной регламентной операции не совпадало с рабочим временем сотрудников вашей организации.
Данная обработка очищает регистр сведений "Версии объектов" по указанную дату. Очистка выполняется методом "кусочных" запросов на конкретную дату. Сделано так, ввиду того что за один день может быть по несколько тысяч записей. После очистки оставшиеся версии с большей датой можно просмотреть в обычном режиме. Минус в номерах версий. Предположим было 5 версий. 3 первых удалили . Тогда для анализа доступны версии с номером 4 и 5. В качестве примера: Размер архива .dt до чистки регистра 1,62 Gb после очистки информации за 4 месяца размер архива .dt стал 1,29 Gb.
У каждого была проблема «растущего» регистра "Версии объектов". Мы дорастили просто до чудовищных размеров(20 мил.) почистить обработкой очень трудоемко, плюс баз у нас много. Решили написать регламентное задание.
Чистит каждую ночь по 5 часов
Удаляет записи прошлых лет
Оставляет всегда 1 самую старую версию.
После отработки пишет в журнал регистрации информацию по проделанной работе.
Все входные параметры легко зашиваются на константы.
Проверено на УПП 107.2.1.3 платформа (8.3.8.1933).
После очистки рекомендую сделать сжатие базы.
Листинг регламентированного задания.
Помидорами не кидаемся.
Специальные предложения
Мне кажется так будет быстрее + время будет тратиться только на удаление существующих записей + можно получать данные для удаления порциями
Пока Выборка.Следующий() Цикл
Далее уже отборы и запись.
Есть ряд замечаний:
1. не понятно, вы хотите оставить самый первый или самый последний экземпляр? Удаляя все записи, кроме первой или последней, вы лишаете себя возможности видеть все изменения, вносимые пользователями. В результате прояснить: кто, когда изменил документ и что изменено не представляется возможным. ( в случает отличия с печатной формой).
2. Ежедневно выставляя параметр запроса "Период" как начало года, вы не уменьшаете объем данных регистра за текущий год.(т.е. весь текущий год регистр растет)- текущий год не обрабатывается. ( запускать обработку ежедневно не имеет смысла - только раз в году). Обработав первый раз регистр "Версии объектов" в 2018 году, набор данных за 2017 год и ранее мало изменится, т.к. вам навряд ли разрешат изменять данные закрытых периодов, а реквизит регистра ДатаВерсии будет = дате записи, внесения изменений или перепроведения - в любом случае>01.01.2018
Постановка задачи:
Оставляем самую свежую запись за 2017 год.Общая история хранится в бекапах.
При больших объемах регистра в 20 мил записей до 2017 г. удалять приходится порциями.
Закрытие периода не влияет на регистр "Версии объектов". Ночные задания проходят под правами администратора.
Все входные параметры(Период отбора, Количество оставляемых версия, Время работы) можно зашить на Константы в таком случае работа механизма будет гибкой.
у себя для очистки версий использую следующий принцип:
1) запросом выбираю объекты, которые не изменялись с какого-то момента времени (например с 01.01.18) - эти записи уже можно назвать условно постоянными и история по ним в рабочей базе не так важна.
обращаю внимание что определения переменных НЗ и ОТБОР вынесены за пределы цикла. 480 тысяч записей по 130 тысячам объектов были освобождены в течение 5-6 минут.
У каждого была проблема «растущего» регистра "Версии объектов". Мы дорастили просто до чудовищных размеров(20 мил.) почистить обработкой очень трудоемко, плюс баз у нас много. Решили написать регламентное задание.
Чистит каждую ночь по 5 часов
Удаляет записи прошлых лет
Оставляет всегда 1 самую старую версию.
После отработки пишет в журнал регистрации информацию по проделанной работе.
Все входные параметры легко зашиваются на константы.
Проверено на УПП 107.2.1.3 платформа (8.3.8.1933).
После очистки рекомендую сделать сжатие базы.
Листинг регламентированного задания.
Помидорами не кидаемся.
Специальные предложения
Мне кажется так будет быстрее + время будет тратиться только на удаление существующих записей + можно получать данные для удаления порциями
Пока Выборка.Следующий() Цикл
Далее уже отборы и запись.
Есть ряд замечаний:
1. не понятно, вы хотите оставить самый первый или самый последний экземпляр? Удаляя все записи, кроме первой или последней, вы лишаете себя возможности видеть все изменения, вносимые пользователями. В результате прояснить: кто, когда изменил документ и что изменено не представляется возможным. ( в случает отличия с печатной формой).
2. Ежедневно выставляя параметр запроса "Период" как начало года, вы не уменьшаете объем данных регистра за текущий год.(т.е. весь текущий год регистр растет)- текущий год не обрабатывается. ( запускать обработку ежедневно не имеет смысла - только раз в году). Обработав первый раз регистр "Версии объектов" в 2018 году, набор данных за 2017 год и ранее мало изменится, т.к. вам навряд ли разрешат изменять данные закрытых периодов, а реквизит регистра ДатаВерсии будет = дате записи, внесения изменений или перепроведения - в любом случае>01.01.2018
Постановка задачи:
Оставляем самую свежую запись за 2017 год.Общая история хранится в бекапах.
При больших объемах регистра в 20 мил записей до 2017 г. удалять приходится порциями.
Закрытие периода не влияет на регистр "Версии объектов". Ночные задания проходят под правами администратора.
Все входные параметры(Период отбора, Количество оставляемых версия, Время работы) можно зашить на Константы в таком случае работа механизма будет гибкой.
у себя для очистки версий использую следующий принцип:
1) запросом выбираю объекты, которые не изменялись с какого-то момента времени (например с 01.01.18) - эти записи уже можно назвать условно постоянными и история по ним в рабочей базе не так важна.
обращаю внимание что определения переменных НЗ и ОТБОР вынесены за пределы цикла. 480 тысяч записей по 130 тысячам объектов были освобождены в течение 5-6 минут.
В технологической платформе 8.3.11 был введен специальный механизм — «История данных». Этот механизм видится достаточно полезным, так как предоставляет ту функциональность, которую не редко приходится реализовывать вручную. В этой статье я попробую рассказать о том, что это за механизм, для чего он нужен и как с ним работать.
Общая информация
Начнем с общей теоретической информации о том, что такое история данных и как она устроена.
Описание и возможности
История данных — это механизм позволяющий хранить в базе данных упорядоченные по времени версии объектов конфигурации. Под версией понимаются данные, которые были в объекте на момент редактирования и состояние метаданных на момент редактирования. Хранить историю можно как для всего объекта целиком, так и для отдельных реквизитов — имеется возможность тонкой настройки работы механизма для каждого реквизита, в том числе табличные части.
Включать и выключать историю можно как из конфигуратора, так и средствами встроенного языка, все это дает возможность управлять историей для каждого пользователя отдельно.
Само по себе хранение истории достаточно бесполезная функция, поэтому с историей данных можно выполнять следующие операции:
- записывать версию данных;
- получать данные определенной версии;
- удалять данные определенной версии;
- получать разницу между двумя версиями одного объекта;
- прочие полезные возможности.
На момент написания статьи (8.3.13) история данных поддерживается для следующих объектов:
- общие реквизиты;
- константы;
- справочники;
- документы;
- бизнес-процессы;
- задачи;
- регистры сведений;
- планы обмена;
- планы счетов;
- планы видов характеристик;
- планы видов расчетов;
- расширения конфигурации.
Работа с историей данных регулируется правами доступа и отражается в журнале регистрации.
Устройство механизма
История данных хранится в специальных таблицах информационной базы. Кроме самих данных в этих таблицах хранятся метаданные прежних версий объектов. Версии метаданных создаются в момент изменения этих самых метаданных у объекта и никак не связаны с изменением данных объекта.
Также следует помнить, что на данный момент система не отличает включение версионирования для реквизита от создания реквизита и отключение версионирования реквизита от удаления реквизита.
Создание версии объекта состоит из двух этапов. Сначала, автоматически или с помощью специального метода, фиксируется факт изменения объекта и информация об этом изменении попадает в очередь. Перенос данных из очереди в таблицы базы выполняется методом ОбновитьИсторию(), этот метод можно выполнять асинхронно, например регламентным заданием. Идущие подряд изменения одного объекта не «склеиваются» и фиксируются отдельно, вне зависимости от периодичности обновления истории данных.
Настройка версирования объектов осуществляется либо из конфигуратора либо при помощи встроенного языка. Конфигуратор логично использовать в тех случаях, когда история данных потребуется во всех режимах работы приложения или на нее завязана какая-то прикладная логика. Использование встроенного языка потребуется для реализации более гибкой системы, например когда пользователя потребуется самому выбирать для каких объектов хранить историю данных.
Для управления историей данных объектов в конфигураторе реализовано свойство «История данных», оно присутствует как у основных объектов (у справочников, например) так и у подчиненных — реквизиты, табличные части с их реквизитами, ресурсы регистров сведений.
Свойство «История данных»
По умолчанию свойство «История данных» установлено в значение «Использовать» у:
- стандартных реквизитов;
- реквизитов объектов;
- реквизитов табличных частей;
- измерений регистров сведений (без возможности отключения);
- ресурсов регистров сведений.
Использование механизма
Для обращения к истории данных используется свойство глобального контекста ИсторияДанных, методы этого этого свойства будут рассмотрены ниже.
Управление использованием истории данных
Ниже приведены примеры того, как, средствами встроенного языка, можно управлять использованием истории данных. Отмечу, что значения свойства ИсторияДанных (полученные «через точку») берутся из конфигуратора и могут не соответствовать действительности, для получения актуальной информации нужно пользоваться методом ПолучитьНастройки().
Здесь Вы получаете доступ к публикациям, в которых профессионалы делятся своим уникальным опытом. Для Вас мы собрали более 30 000 различных материалов по 1С.
Рейтинг: 255
Данная обработка очищает регистр сведений "Версии объектов" по указанную дату. Очистка выполняется методом "кусочных" запросов на конкретную дату. Сделано так, ввиду того что за один день может быть по несколько тысяч записей. После очистки оставшиеся версии с большей датой можно просмотреть в обычном режиме. Минус в номерах версий. Предположим было 5 версий. 3 первых удалили . Тогда для анализа доступны версии с номером 4 и 5. В качестве примера: Размер архива .dt до чистки регистра 1,62 Gb после очистки информации за 4 месяца размер архива .dt стал 1,29 Gb.
Добавлена возможность прерывания по Ctrl+Break.
Специальные предложения
Народ столкнулся с этой проблемой.
Ситуация: в организации несколько лет работал механизм версионирования, год назад был отключен. Нужно полностью очистить регистр с Версиями объектов. В принципе проблем никаких пишем обработку удаляем записи регистра.
Вопрос: нужно ли удалить что-то еще кроме записей регистра? И не будет ли в дальнейшем каких либо проблем?
Тоже планируем сделать такую только удаление хотим сделать не на определенную дату, а в случае если версии за две даты ни чем не отличаются.
Такое часто бывает например перепровели документ не изменяя реквизитов.
Или зашли в элемент справочника, а когда выходили нажали не на кнопку закрыть а на кнопку ок.
Все это попадает в регистр(но таким записям там явно делать нечего, только размер базы пухнет).
мда. такие штатное 1С-ное версионирование дюже хромое
Если кому интересно, у уважаемого O-Planet есть собственная разработка вроде как достойного качества. Лог выгружает в отдельную базу.
Так собственно, на вопрос то никто не ответил.
Удалять то можно просто из регистра? Никаких косяков в районе целостности базы не будет? Обработку то писать 5 минут. У меня вопрос, не будет ли проблем потом?
(6). Периодически с определенным интервалом запускаю данную обработку на базе УПП. Проблем с целостностью базы не наблюдаю.
Спасибо:) Работает. Регистр почти в 5 миллионов записей удалось сократить на треть. В качестве пожелания разработчику: если бы еще бы можно было настраивать отборы (например документы за определенный месяц) чтобы была возможность запускать обработку частями - было бы вообще идеально. А то в том случае, когда количество обрабатываемых документов приближается к паре миллионов дело может затянуться:)
немного долго - если достаточно большой период для удаления, но все работает. Не хватает: при необходимости прервать работу обработки, Ctrl-Break не работает.
и относительно самого версионирования, к сожалению не нашел ни одного отчета, который позволяет сформировать статистику изменений не по одной позиции, а по определенному набору или хотя бы определенному справочнику используя этот механизм. Придется попробовать самому разобраться, хотя наверное не все тут так просто в использовании этого механизма, если до сих пор таких отчетов никто так и не сделал.
Вообще просто удалять неправильно.
Лучше создать отдельно базу с одним РС ВерсииОбъектов и перегружать туда данные.
Обработка вычищает все записи на хер, не оставляя последних. потом не с чем будет сравнивать измененную версию объекта.
Прошли реорганизацию, оставили по старой конторе базу. Использовал обработку, с 3 ГГ упало до 2 ГГ. Плюс.
Пришел к этой проблеме совсем с другой стороны, открыл для себя много нового что и вам поведаю.
Предыстория:
В один "прекрасный" день база перестала быть адекватной минув барьер 4 гб (не давала сохранять документы и т.д -вылет с ошибкой).
Сначала грешили на почту подключенную в 1с. Решили удалить переписку но база уже не давала -ее просто заклинило и выбивало с ошибкой даже при попытке что то удалить. Не знаю как но бухгалтер умудрилась все таки что то удалить после чего базу немного попустило и стало возможно удалить переписку, но объем уменьшился не на много. Я в это время на копии пытался шаманить -выгружал базу в файл загружал обратно, тестировал и реорганизовывал таблицы через конфигуратор -ничего не дало результат, объем был непоколебим. Уже было решили кинуться в крайность - перейти на sql вариант, все программисты так и советовали) но там свои заморочки и я решил разобраться в проблеме все таки. Покопал немного в сети и нашел программу просмотра таблиц базы, вместе с бухгалтером поняли что как раз таблица версий занимает эти предельные 4 гб на таблицу (для файловой 1с). Теперь пробую варианты уменьшить таблицу - один из них использовать штатную обработку 1с в УТП это "универсальный обмен данными в формате xml". там есть секция удаление данных, но нету возможности удалять по дате а только все данные и так как процесс ресурсоемкий то опять же вылет с ошибкой "нехватка памяти" (это уже ограничение самой ОС на 32 битные приложения) и снова надо шаманить уже над ОС чтобы перешагнуть этот барьер. Остается вариант написать самому что то или вашу обработку пробовать, вариант сделать свертку базы тоже бухгалтер не очень хочет так как не очень ей удобно пару баз иметь. Так что такие обработки из разряда стратегически важных потому что на весах сохранность всей базы, ведь проблема не только в ее объеме но и в дальнейшем функционировании и без вовремя сделанной копии восстановить работоспособность не просто (при пороге 4 гб свертка тоже не работает уже, база просто в нокдауне, хоть бери да ножом режь).
(g123) спасибо за столь развернутый комментарий. По своему опыту могу сказать, что когда возникает подобная проблема, то лучше все же перейти на SQL.
Я поглядел код этой обработки и что-то мне показалось не сильно оптимально читать данные из регистра, потом их записывать привязывая на пустую ссылку, чтобы потом отбором по ней грохнуть данные.
в общем запилил альтернативный код для кнопки выполнить
Уж лучше удалять со ссылками на объекты, помеченные на удаление, если они не нужны, и по одной версии остальных оставлять.
Недостаток обработки - что записи регистра сначала не удаляются, а:
1. записываются с Объект = Справочники.Номенклатура.ПустаяСсылка()
2. и только потом удаляются все записи с этой пустой ссылкой.
И если включено версионирование Номенклатуры, то при попытке записать элемент справочника Номенклатура пока не завершён п.2 - будет выдана ошибка записи.
Читайте также: