Друзья, всем бобра и счастья!
Дисклеймер! Политика 1С не разрешает никакие манипуляции с данными напрямую средствами СУБД, только средствами платформы! Поэтому качать, смотреть, думать, а уж тем более запускать эту обработку категорически нельзя. (или можно, но только ночью, обязательно завесив окна, выключив свет и закрывшись на семь замков). Шутка, конечно же. Просто в случае безвозвратной потери данных виноваты будете Вы и только Вы. Минздрав предупредил.
Цель написания обработки единственная: создание БД для разработчика в максимально короткие сроки путем обрезки базы до минимума, необходимого для работы. Никакая целостность не проверяется и не гарантируется. Возможно, кто-то уже сталкивался с проблемой в больших компаниях, когда база 1С весит сотни гигов (по несколько млн документов в год), и развернуть каждому программисту в отделе по отдельной копии просто физически невозможно. И не рентабельно. Лучшее решение — обрезать базу, оставив в ней данные лишь за небольшой период. Но удаление большого числа объектов средствами 1С занимает очень много времени.
В качестве статистики приведу пример. 1С у меня удаляет данные со скоростью ~25 000 объектов/час, Обработка — ~2 000 000 объектов за 20 минут. Разница налицо, как говорится.
За основу идеи была взята обработка //infostart.ru/public/122546/ . За что огромное спасибо автору и долгих лет жизни. К сожалению, столкнулся с единственной проблемой — скорость работы. Поэтому решил полностью изменить алгоритм.
Как пользоваться обработкой?
Аутенфикация
Некоторые данные для аутенфикации подтягиваются автоматически из строки соединения с ИБ, но они совсем не всегда совпадают. Поэтому необходимо ввести имя именно своего сервера SQL.
Для проверки корректности данных есть кнопочка «Проверить подключение».
Тайм-ауты можно оставить как есть. 30 сек для подключения, 1ч на выполнение запроса в СУБД. Если в процессе удаления появится ошибка «(Microsoft OLE DB Provider for SQL Server): Query timeout expired», значит, необходимо увеличить тайм-аут выполнения запроса, т.к. слишком много данных, и СУБД не успела их почистить.
Удаление
Удаление возможно частичное или полное.
Обработка позволяет очищать следующие объекты:
- Документы,
- Журналы документов,
- Регистры сведений,
- Регистры накопления,
- Регистры бухгалтерии.
Полное удаление выполняется быстро через команду TRUNCATE TABLE.
Частичное удаление производится путем выбора периода удаляемых данных (отбор по полю _Period в БД).
Для Документов также автоматически очищаются таблицы, содержащие данные табличных частей документов.
Для Регистров накопления и бухгалтерии есть возможность выбора действия обработки виртуальных таблиц (Итоги, Обороты…). По хорошему, в идеале лучше всего виртуальные таблицы очищать полностью, после чего из Конфигуратора запускать Тестирование и исправление с галкой «Пересчет итогов».
Для Регистров сведений есть возможность выбора Подчиненных или Независимых. Для Подчиненных возможен отбор по периоду регистратора.
Команда «Очистить всё» последовательно проходит по всем страницам обработки и выполняет действия в зависимости от выбранных параметров.
Ну частичное да, а вот полное .. может просто конфу скопировать!? 🙂
Очищать виртуальные таблицы нельзя, т.к. их нет. Если речь о пересчете итогов, то там только одна таблица — собственно, сами итоги. Таблицы оборотов нет.
Ну и пересчитывать итоги после такого грубого вмешательства нужно не «по хорошему», а обязательно.
(1) DoctorRoza, имеется ввиду по объектам метаданных. Удалить полностью за весь период, либо отобрать. Я у себя наиболее используемые документы оставлял за полгода, ненужные — сносил полностью:)
(2) TTSTV, если взять регистр накопления(остатки или обороты), то нужно всегда помнить, что в базе sql помимо основной таблицы с данными лежит еще таблица с итогами (либо оборотами), которая скорей всего в разы больше основной. А у регистров бухгалтерии и не одна (ИтогиПоСчетамССубконто1, ИтогиМеждуСчетами, ИтогиПоСчетам…).
Я тоже считаю, что после такой чистки запуск ТиИ пересчета итогов и переиндексации обязательны. Но возможность удалять данные из виртуальных таблиц частично я всё же оставил.
ТиИ приходится оставлять на ночь, в моем же случае вопрос времени критичнее достоверности данных, поэтому я чистил «по-быстрому» 🙂
Но, опять же, после пересчета итогов и переиндексации получится еще и приличная экономия места.
(4) чтобы итоги не пересчитывать можно после «обрезания» выгрузить и загрузить дтшник средствами платформы, для базы в 100гб операция загрузки занимает примерно 4 часа, выгрузка около часа, но это если не совсем уж дохлый комп.
(4) думаю, что для торга могло бы быть актуально)
Автору респект. Тоже делал подобное для тестовых баз.
И совет для удаления больших таблиц: если удаляется бОльшая часть таблицы, выгоднее сделать копию нужной части данных, очистку таблицы TRUNCATE и копирование обратно. Дело в том, что если у вас одна таблица допустим весит 40Гб, при удалении 95% ее содержимого лог базы данных вырастет примерно на 150Гб.
(7) polyplastic, спасибо:) дада, сталкивался с переполнением логов, поэтому удаление данных таблицы делаю в одной транзакции. Копирование+транкейт+копирование обратно как-нибудь попробую на досуге, интересна скорость отработки данного метода.
Спасибо автору!
Спасибо!!!
И кто из вас украл обработку у другого?????????
При сравнении 1с-ка показывает что они полностью идентичны.
СТОП. Прошу прощения отбой ;))
Сборщик писем подставил — повторно скачал первую обработку 🙂
Таб/части справочников удаляет?
(13) forsagforsag, удаляет) По алгоритму сначала производится удаление табличных частей, а потом и самих документов
Обработка ГУД)) Мне помогло Автору респект
ДО ЭТОГО — пробовал очистить регистр сведений (около 10 миллионов записей — SQL на дохлой тачке) — методом копирования Регистра в конфигураторе и удаления Исходного…. так вот отваливался Конфигуратор по таймауту (потом доперло что «Администрирование/Параметры информационной базы…/ Время ожидания блокировки..» — скорей всего бы помогло )
Надоело экспериментировать… да и время кончилось… начальника ругалась))) скачал обработку выбрал регистр ... поставил галку «Удалить полностью (Truncate table)».
Формируется остатки на начало периода? если задан период
(16) Kontakt, если задается период, то удаляются данные только за этот период. Без формирования остатков. Это не свёртка, а очистка 🙂
(17) stsasha87, Свертку сделал на 31.12.2015 23:59:59 как теперь обрезать и не затронуть. Если период ставится в обработке лишь датой. 30.12.15 ?
(18) Распроведи и перенеси документы свертки на 01.01.2016. потом зачисть и верни все обратно.
ДД! в конфигурации Документооборот будет работать?
(20) Насколько я помню, в Документогороде большинство «документов» — это элементы справочников. У которых «Период» — это отдельный реквизит, который на sql-е скорей всего называется как _FldXXXX, а не _Period. Поэтому если делать частичное удаление по периоду, то надо сначала уточнить имя реквизита в субд и поправить в обработке. А так не вижу помех, но обязательно сначала всё пробовать на копии!
Табличные части документов также как оригинальная чистит муторно и долго или переписано? Оригинальная офигевала если документов заказ покупателя под миллион… очень долго чистила даже с таймаутами дикими.
Добрый день. Данная обработка может работать много поточно? т.е. запустить из разных сеансов удаление разных регистров?
(7) Чтобы не рос лог транзакций, надо удалять пакетами. Это если через Delete From. При этом надо запускать каждый пакет в фоновом процессе. Помогает ускорить процесс довольно заметно.
Добрый день!
А данную обработку как можно переделать, чтобы через скрип запустить?
Олег
(23)
Да, конечно. Никто никому мешать не будет, если удалять разные регистры.
(25) Не совсем понял, зачем через скрипт. Если нужно какое-то периодическое удаление, можно посмотреть код и по аналогии сделать регламентное задание по удалению данных за период.
Для автоматизации. Думаю сделать обрезание данные и формирование БД для разработчика по скрипту. Возможно повешу это на запуск от веб-сервиса — разработчик вводит только что ему нужна свежая БД и получает ее, не имея доступа к серверам SQL и т.д.
(28) Я бы это делал тогда совсем без участия 1С) Скрипт на sql с примерно таким алгоритмом:
1) Транкейтим таблицы Версии объектов и им подобные регистры с ненужными данными
2) Идем по таблицам документов. Отбираем их по DocumentХХХХ и делаем delete по периоду
3) Идём по таблицам регистров накопления, хозрасчетным…. Аналогично делаем delete по периоду. Не забывая про виртуальные таблицы.
и т.д.
И запускать такой скрипт сразу после разворачивания копии базы для разработчика. Всё на стороне субд.
Скачал обработку, но есть пожелание:
сделать возможным удалять документы и все регистры по этим документам. А не отдельно документы и отдельно регистры.
Была задача: удалить из базы все документы и связанные с ними регистры (любые). Остальное (справочники) в базе оставить.
Спасибо! Очень помогла обработка.
Только вот нет очистки таблицы изменений.
не рабортает! В регистрах сведение как были записи так и остались!
Все бы хорошо, но автор погнался за красотой в ущерб эффективности. Для того, чтобы на форме сделать прогресс-бар, он каждый раз заново создает connection и заново его закрывает для каждого вида документа и регистра. 180 видов документов * 30 секунд на эту лабуду — получилось лишних 1.5 часа. Но можно допилить напильником 🙂
Подскажите. Под PostgreSQL что-то подобное есть?
(1)
Если просто скопировать конфу и развернуть из нее новую базу, она потеряет преемственность со старой. Я это проходил, внутренние идентификаторы предопределенных объектов меняются и потом из старой подкинуть что либо средствами xml становится весьма геморно, например перекидываешь обороты по бухучету и у тебя дублируется план счетов, причем предопределенные счета. Это очень мило, ведь 1С-ка когда такое замечает сразу захлопывается.
В принципе годная вещь. Мне нужно было грохнуть все доки с движениями в базе размером 160 гиг. За несколько часов управился. Единственное что осталось недочищенным — последовательности. Особенно партионный учет поднапрягает. Через конфигуратор уже чистится черти сколько, оставлю на ночь — пусть маслает.
(36)
и очистки регистров расчета не хватает