Текст из серии «Письма клиентам», на тему «Свёртка информационной базы». Несмотря на инженерную простоту свёртки, клиенты, в большинстве случаев, неверно понимают её назначение. В этом им помогают менеджеры по продажам, которые слушают, кивают головой и записывают в блокнот пожелания клиента. Подливают масла в огонь слесаря 1С, которые, попробовав применить типовую свёртку и не получив результата за приемлемое время, выносят вердикт: свёртка невозможна. Так появляются задачи «поставьте нам чистую базу и перенесите туда остатки».
Что делает свёртка?
Как сказано выше, свёртка – очень простая в инженерном плане операция. Она делает следующее:
1. Берёт текущие остатки по регистрам и вводит их заново на дату свёртки;
2. Распроводит и помечает на удаление все документы до даты свёртки;
3. Удаляет документы до даты свёртки, какие сможет.
Некоторые обработки, в т.ч. типовые, дополняют этот список какими-то опциями. Например, свёртка в ЕРП утверждает, что умеет удалять неиспользуемые элементы справочников. Свёртка в БП3 говорит, что может проверить введённые остатки – сверить их с существующими, где-то между пунктами 1 и 2.
Но в целом, свёртка делает три указанных шага.
Зачем делать свёртку?
Любое действие в информационной делается для того, чтобы что-то в ней изменить. Что изменится после свёртки?
Смотрим ещё раз на 3 шага и думаем. Остатки у нас не изменятся – они «перевводятся» «как есть». Но: остатки будут удобненько лежать в виде специальных документов (ручных операций, корректировок регистров). Соответственно, их значительно проще исправлять, если есть такая потребность. Станет сильно меньше данных в некоторых таблицах – документы до даты свёртки и их движения по регистрам исчезнут. Соответственно, уменьшится физический размер базы.
Итак, каких приличных целей поможет добиться свёртка:
1. Уменьшить размер информационной базы;
2. Получить более удобный инструмент корректировки остатков;
3. Удалить из базы документы, которые мы, по каким-то причинам, не хотим видеть (показывать).
Это – приличные цели. Есть и неприличные.
Чего свёртка не сделает
Часто бывает – благодаря менеджерам и слесарям – что клиент, не получив нормальных разъяснений про свёртку, начинает фантазировать.
Как правило, он думает, что свёртка исправит ошибки в учёте. Чаще всего такой запрос приходит от клиентов, которые внедряли-внедряли, потом «всё поняли», и теперь им надо исправить ошибки прошлого. Особенно в современных конфигурациях, вроде ЕРП, КА2 или УТ, где через несколько релизов разработчики «всё поняли», бросили один регистр и стали использовать другой.
В регистрах накапливается масса ошибочных данных – минусов, неверных значений измерений, дублей производных справочников и т.д. Избавиться от всего этого обычными средствами клиенту не представляется возможным, и он сам себя накручивает на тему «свёртка всё исправит». Поймёт, где что не так, удалит кривизну, схлопнет дубли и приберёт за шкафом.
Так вот – не исправит. Смотрим п.1 из действий свёртки: остатки будут ровно такими же, просто слягут в один документ.
В каких конфигурациях есть свёртка?
Нужно проверять, т.к. всё меняется и развивается. Например, ещё недавно в ЕРП и КА2 не было свёртки, а теперь появилась. Как правило, обработка свёртки лежит прямо в конфигурации. Есть универсальные, подходящие под разные конфигурации.
На момент написания публикации свёртка точно есть в УТ 10.3 и УПП, ЕРП и КА2, БП2 и БП3. В ЗУПе вроде до сих пор нет.
Всё или ничего
Обработки свёртки в современных конфигурациях устроены, как правило, по принципу «всё или ничего». Они сворачивают или всё сразу – все документы и регистры – или ничего. Раньше – в той же УПП – свёртка настраивалась более гибко, индивидуально для каждого документа и регистра.
Причины вижу две.
Первая – разработчики свёртки понимают, что раньше эту операцию выполняли программисты, а теперь – пользователи и слесаря. Программист мог разобраться, какой регистр можно оставить несвёрнутым (в справке к свёртке были написаны толковые рекомендации на эту тему). Пользователь и слесарь, разумеется, этого сделать не смогут.
Вторая причина – конфигурации стали сильно сложными в плане архитектуры, со множеством взаимозависимостей на уровне документов и регистров. Теперь уже ни программист, ни разработчик типовой конфигурации не смогут гарантированно ответить, что произойдёт после частичной свёртки.
Соответственно, если клиент хочет использовать типовую свёртку, придётся учитывать фактор времени, т.к. операция почти неделимая.
Примерный алгоритм выполнения типовой свёртки
Главное – не делать свёртку сразу в рабочей базе. Можно натолкнуться на массу неприятностей, от ошибок СУБД до падения из-за доработок, сделанных каким-нибудь пытливым слесарем.
Делаем копию базы, засекаем время, запускаем свёртку. Ключевое значение имеют шаги 1 и 2 – ввод новых остатков и распроведение документов. Мысленно их можно объединить в один этап, т.к. нельзя сделать шаг 1 и не сделать шаг 2 – остатки задвоятся. Шаг 3 (удаление помеченных документов) можно сделать и потом.
Если свёртка прошла успешно – смотрим, сколько она заняла времени. Варьируется обычно от нескольких часов до нескольких суток. Примерно столько же времени займёт свёртка рабочей базы (если делали на идентичном или том же самом оборудовании). Во время свёртки в базе не должно быть пользователей. Теоретически, свёртка не требует монопольного режима, но, если в базе будут работать люди, может случиться конфуз, или целый их фейерверк.
Например, будут возникать конфликты блокировок. Если отвалится у пользователя – фиг с ним, переживёт. Если упадёт свёртка – намного хуже. Она, как правило, не умеет остановиться и продолжить с того же места – тот самый принцип «всё или ничего». Ещё могут возникнуть ошибки в данных, т.к. в процессе свёртки остатки будут бешено скакать – можно списать то, чего нет, и уйти в минус.
Если время свёртки меньше 12-16 часов, можно провернуть дело ночью. Если пара суток – в выходные. Если неделю – ждите новогодних каникул.
Да, разумеется, перед выполнением свёртки нужно сделать бэкап. Если придёте утром и обнаружите, что свёртка упала – например, из-за отключения электричества – сможете восстановить базу из бэкапа.
Свернуть за ночь или выходные обычно получается что-нибудь вроде БП3 или КА2. Большие системы, вроде УПП или ЕРП, в которых несколько лет вели учёт, за приемлемое время свернуть не получается. Точнее так: нет возможности остановить работу на такое время, которое требуется для свёртки.
В таких случаях нужна итерационная свёртка. Есть несколько алгоритмов её выполнения.
Типовая итерационная свёртка
Самый простой вариант, для ленивых. Например, учёт ведётся с 2010 года, а свернуть хочется на начало 2020 года, но замер показал, что требуется 2 недели.
Можно сворачивать по одному году. Сначала на начало 2011 года, потом на начало 2012 года и т.д. Типовая свёртка такие штуки нормально переваривает. Она будет каждый раз создавать новые остатки, убивать предыдущие, распроводить документы и помечать их на удаление.
Если свёртка одного года тоже идёт непозволительно долго, можно сворачивать по месяцам. Тоже относительно приемлемый вариант.
Итерационная свёртка по регистрам
Это уже нетиповой вариант, придётся программировать. Хотя, программирование достаточно простое.
Нужно написать обработку, которая будет сворачивать конкретный регистр. Действия она должна делать два:
1. Вводить остатки по регистру, как это делает типовая свёртка;
2. Удалять движения по этому регистру у всех документов до даты свёртки.
Если чуть поднапрячься, то обработку можно написать почти автоматическую. Например, чтобы она брала все регистры накопления, пошагово сворачивала, могла остановиться плюс/минус в заданное время и могла понять, какой регистр она уже свернула, а какой – нет.
Итерационная чистка
Если цель – уменьшение размера базы, то сначала надо остановиться и подумать. Возможно, свёртка – не самый подходящий инструмент для достижения этой цели.
Физический размер базы складывается из размеров таблиц – справочников, документов, регистров, виртуальных таблиц (остатки, обороты). Свёртка удалит документы и движения по регистрам. Но может статься, что главные пожиратели дискового пространства сидят в другом месте.
Увидеть размеры таблиц очень просто. Надо или найти готовую обработку, или написать свою – платформа научилась показывать физический размер таблиц. И от полученных данных плясать – удалять целенаправленно то, что занимает больше места.
Я приведу несколько примеров таблиц, которые на практике оказывались самыми большими. Сократить их размер поможет программист, и сделает это без свёртки.
Присоединённые файлы и картинки. Частенько бывает: кто-то когда-то решил загрузить кучу файлов, сделал это, а потом сел думать – а нафига? Так и не придумал, а файлы остались. Например, присоединённые файлы документов того периода, который собирались свернуть.
Версии объектов (например, в УПП это регистр сведений). Там может лежать по 20-50 версий каждого документа того периода, который всё равно собирались свернуть. По размеру эти данные могут занимать десятки гигабайт.
Виртуальные остатки незакрываемых регистров накопления. Это когда приход делается по одному набору аналитик, а расход – по другому. Например, в регистре накопления «Заказы поставшикам» есть измерение «Цена». Если заказывать по одной цене, а приходовать по другой, то виртуальная таблица остатков начнёт быстро пухнуть. Ещё такое случается, когда какой-то функционал используется наполовину – приход делается, а расход нет. Например, если в УПП не рассчитывать себестоимость, то регистры «УчетЗатрат» и «УчётЗатратРегл» быстро распухнут от накопленных затрат. То же касается регистров НДС. Ну и отдельно отмечу архитектурные ошибки доработок – увы, пухнущие регистры накопления, добавленные слесарями, встречаются довольно часто.
Дикие табличные части. Это, как правило, следствие доработок «высокого уровня» - например, когда делают планирование. Загоняют 10 000 строк в табличную часть какого-нибудь самописанного документа, вроде «Дефициты производства» или «Позиции к заказу», и пишут регламентное задание, создающее такой документ каждый день. Вот оно и копится.
И т.д. Алгоритм очистки простой: определяем размеры таблиц, выбираем «жертву», пишем обработку устранения, выполняем и смотрим, что получилось. Возможно, до свёртки дело не дойдёт.
Удалите всё!
И напоследок – самая часто встречающаяся причина свёртки. Надо полностью удалить все документы, их движения и «следы» за определённый период. Честно не знаю, зачем это делается, но раз надо – значит надо.
Алгоритм простой:
1. Делаем типовую свёртку;
2. Вычищаем, что осталось;
3. Удаляем следы.
По трудозатратам (и бюджету) тут работает принцип Парето: 20% на свёртку, 80% на вычистку и удаление следов.
Сначала вычищаем. Типовая свёртка всегда оставляет неудалёнными кучу первичных документов, потому что на них есть ссылки – или в последующих документах, или в остатках регистров. Принципиально есть три подхода к вычистке.
Первый – удаление без контроля ссылочной целостности. Это когда прям срочно надо. В остатках и последующих документах остаются оборванные ссылки («Объект не найден…»), с которыми потом придётся разбираться – они будут приводить к ошибкам в работе.
Второй – обезличивание документов. Пишем обработку, которая заходит в каждый помеченный на удаление документ, очищает все его реквизиты и табличные части, стирает дату и номер, кидает все документы одного типа на одну дату. Способ достаточно быстрый и дешёвый, но ошибки тоже могут возникать, особенно в отраслевых конфигурациях – они любят обращаться к реквизитам документов, торчащих в остатках в качестве измерений.
Третий – персональная чистка каждого вида документов. Пишем обработку, которая выведет все документы сворачиваемого периода и считает их количество. Берём самый часто встречающийся и ищем, где на него лежат ссылки. Обычно это какое-то одно место – например, остатки конкретного регистра. Идём и пытаемся понять, нафига этому регистру ссылка на документ. Если понимаем, что особой ценности в ссылке нет – или очищаем ссылку, или подсовываем всем записям одну ссылку. Если понимаем, что ценность есть – обработкой делаем обезличивание. Выполняем удаление помеченных, смотрим чем кончилось. И так по кругу, до победного.
Ну и следы стираем. Главным образом смотрим на систему версионирования. Тут вот в чём фишка: обработка удаления помеченных объектов, когда проверяет наличие ссылок на удаляемый объект, сознательно исключает из этого списка версионирование. Т.е. может случиться так, что документ успешно удалился, а его версии в регистре сведений остались.
А кто такие «версии»? Это упакованный в xml документ, который вполне можно достать и посмотреть.
Ещё бывает, что установлена какая-нибудь отраслевая или самопальная система версионирования. Такие вполне могут хранить версии в справочнике или, что страшнее – в отдельной базе, с которой настроен обмен. Такие следы никакая обработка не найдёт, тут надо быть внимательным.
Ну, и журнал регистрации неплохо бы почистить. И бэкапы поудалять. Но это уже другая история, за пределами свёртки.
Собственно, всё. Сворачивайте на здоровье.
Готовое решение
Database Compression Tool (DCT): Универсальный инструмент сжатия, свертки и конвертации баз данных 1С
Универсальный инструмент сжатия, свертки и конвертации баз данных 1С.
Свертка баз данных еще никогда не была такой простой и быстрой!
DCT ускоряет работу базы, освобождая гигабайты пространства и повышая производительность системы. Доступна ДЕМО версия!
