Как удалить десятки организаций и миллион записей из базы 1С, не привлекая внимания пользователей
Но, как говорится, есть один нюанс…
Казалось бы, решение такой задачи достаточно простое: инструментами разработчика найти все метаданные, где упоминаются необходимые организации, и удалить их.
На практике же… мы столкнулись с тем, что работы в базе ведутся давно. Записей было ОЧЕНЬ МНОГО, семизначное число. Найденные записи ещё и являлись владельцами других метаданных, которые также надо было удалить или отредактировать. Нам необходимо было получить все данные сразу, а не порциями по 1000–5000 записей — и это не получалось. Инструменты просто не справлялись с выполнением такого запроса: в лучшем случае получали данные слишком долго, а чаще просто зависали.
Решить задачу типовыми средствами в нужное технологическое окно в 24 часа и со сроком проекта 1 месяц, как хотел заказчик, виделось невозможным.
Ищем альтернативные способы удаления
Мы рассмотрели несколько моделей реализации удаления организаций:
- Изначальный — с инструментами разработчика. Просто, но занимает слишком много времени.
- Анализ ИБ вручную — найти все метаданные, где упоминается организация, составить запрос для получения сразу всех данных. Тоже просто, тоже тратится много времени на получение результата.
То есть, основная проблема — это время получения. Коллективным решением разработчиков (в котором были, в том числе, специалисты по сверткам баз 1С) была рассмотрена еще одна модель.
- Работа напрямую с таблицами базы данных. Как бы свертка, которая будет не совсем свертка: получить прямыми запросами все данные и тем же способом проанализировать их и обработать. На этом способе и остановились.
Доступ к базе — не панацея
Чем хорош метод работы с базой напрямую? Можно не только получать данные, но и сразу оперировать ими: редактировать, удалять и т. п. — как всю таблицу, так и отдельные строки. Но, тут как в медицине, удалять без анализа — неправильно.
Чтобы понять, какими записями в базе пользуются — взяли документы синхронизации ЭДО. Из оставшихся взяли организацию, которая имеет наибольшее количество записей в ИБ, и запросами получили все возможные цепочки документов. Простейшая цепочка по документам: Организация → договор организации → документы, где этот договор используется.
Следующий этап — работа с бизнес-пользователями. В нашем случае 3 раза в неделю проводились консультации с ИТ-отделом, аналитиками и бухгалтерами, добавляли дополнительные блоки для получения данных. То есть сам по себе прямой доступ к базе — не панацея.
Для оптимизации удаления мы выстроили следующий порядок удаления данных:
- Независимые регистры, связанные с удаляемыми документами.
- Документы и их движения. Зависимые регистры.
- Независимые регистры, связанные со справочниками.
- Справочники.
Повторим, что всё это делаем на примере одной организации, чтобы минимизировать возможные негативные последствия и быстро получить промежуточный результат. На этапе удаления также продолжаем консультации с бизнес-пользователями. И снова корректируем запрос.
После — обязательный поиск битых ссылок. Разворачиваем дополнительную копию базы, проверяем в ней количество «изначальных» битых ссылок — это будет эталон, с которым будем сравнивать дальнейшую работу. Битых ссылок в нашем проекте было до удаления: 42 000, после стало 45 000. Все эти ссылки проверяем и удостовериваемся, что они не мешают корректной работе всей базы:
- проверяем, используется ли где-то битая ссылка — если нет, то ок;
- если данная ссылка влияет на работу в базе, то:
- восстановить битую ссылку из бекапа;
- либо заменить на ссылку, которая будет служить заглушкой.
Например, подразделения организации — данный справочник используется в бухгалтерских регистрах и важно было его сохранить. Или договор контрагента, «зашитый» в коде — после удаления этого договора, механизм корректно не отрабатывал, пришлось такой договор заменять на «заглушку».
Документы должны работать в штатном режиме, остатки по регистрам должны корректно отображаться.
Результаты
Итерационно оперируя конкретными цепочками, конкретными документами, мы получили финальный запрос по поиску и удалению информации, работа которого занимало желаемое время. У нас он получился универсальным — то есть мы его запустили по всем необходимым организациям. При запуске на продуктивном контуре удалось уложиться в 12 часов.
По окончанию процесса заказчик тщательно все протестировал: по всем процессам не было ни одного замечания — регистры сходились, отчеты отрабатывали корректно, данные не были искажены.
Таким образом, используемая при решении задачи методика показала — при хорошей подготовке даже большой объем работы с данными можно уложить в маленькое технологическое окно и сделать это без ошибок.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
