Любая база данных со временем разрастается до огромных размеров, что делает его более медлительным и работать в нем порой бывает очень тяжело.
По этому периодически базу свертывают, т.е. до определенной даты все документы и движения удаляются и вводятся начальные остатки. Соответственно всегда есть архивная база за прошлые периоды.
Пример свертки базы 1С на SQL приведен здесь.
Предыстория
В компании, где я работаю, возникла ситуация, когда настала необходимость урезать базу, т.е. удалить все документы и движения до определенной даты. К этому моменту база данных весила почти 350Гб, и очень тяжело было с ним работать. Также страдало быстродействие 1С и регламентные операции с БД выполнялись очень долго.
Решение было принято — базу обрезаем! После долгих тестов типовых обработок по свертыванию, я в них разочаровался. Больше двух недель провел наедине с компьютером обрезая тестовую базу. Такие сроки просто недопустимы в рабочей базе, тем более в базе работают пользователи 6 дней в неделю. Как то нужно было выбираться из тупиковой ситуации. Решили передать задачу на аутсорс. Но и здесь нас не обрадовали, стоимость работ высокая и время для выполнения требовалось немаленькое.
В общем вопрос оставался нерешенным и вернулись к тому, чтобы решить задачу своими силами.
Пришлось прибегнуть к крайним мерам, я отключился от всех других задач и взялся за свертывание базы.
И в скором времени вопрос был решен — обрезали базу за 2 дня, уменьшили его на 70%.
Обрезание базы УТ с объемом 350 Гб за 2 дня.
Решил выполнить задачу по такому алгоритму:
Создать копию рабочей базы. В копии сформировать остатки на нужную дату, удалить все документы и движения до этой даты. Далее из рабочей базы все новые документы (созданные с момента создания копии) перенести в новую базу. Пустить пользователей в новую базу.
Задача была разделена на 5 подзадач:
1.Создать план обмена, для того чтобы после обрезания базы все новые документы можно было перенести в новую базу.
2.Сформировать остатки на дату свертки.
3.Удалить все документы и движения до даты свертки.
4.Загрузить документы из текущей базы в новую базу.
5.Заменить рабочую базу новой (обрезанной) базой.
На подготовительный этап ушло около двух недель: создание плана обмена, поиск инструментов по созданию остатков и очистки регистров, тестирование механизмов.
Процесс свертки базы данных.
1. Формирование остатков на дату свертки.
Остатки формировал типовой обработкой «СверткаБазы.epf».
Чтобы сэкономить время формирование остатков выполнил в рабочей базе в рабочее время. Т.к. остатки формируются документами «Корректировка записей регистров» и обработка устанавливает неактивными движения в регистрах, то эта процедура для базы безвредна.
В обработке поставил ограничение на количество строк в одном документе 50 000.
Делал не спеша, и в течении 1-2 дня все сформировалось (получилось около 400 документов).
Примечание:
— если на дату свертки есть документы «Корректировка записей регистров» не связанные со сверткой базы, то их лучше перенести на дату позже, чтобы случайно их не перепутать потом.
— при формировании остатков, лучше просмотреть все регистры, т.к. бывает, что не по всем регистрам начальные остатки вам нужны. Иногда бывают ситуации, когда регистр уже нигде не используется. В итоге это сэкономит ваше время.
2. Создать полный план обмена для выгрузки в идентичную конфигурацию (можно делать параллельно формирования остатков).
3.В нерабочее время очистить зарегистрированные в плане обмена объекты и сделать копию базы с отключенными регламентами.
4.Удаление документов и очистка регистров.
Эта операция самая медленная и для ускорения этой операции нужно использовать прямые запросы SQL . Подобные инструменты можно найти на Инфостарте. Есть еще один момент, если мы удалим данные таким способом, то объекты удалятся быстро, но без контроля на ссылочную целостность. Соответственно, в наших документах вода остатков и других документах появятся строки типа «Объект не найден….».
У меня стояла задача оставить эти документы в непроведенном виде для информационных целей.
Для этого была написана обработка, которая сняла с проведения и перенесла на дату свертки все документы участвующие в движениях в документах корректировки регистров.
После чего, используя обработку по удалению документов и движений через SQL запросы, удалить все до даты свертки (журналы документов, документы, регистры накопления, регистры сведений и т.д.).
Примечание:
— по регистрам сведений нужно чистить только периодические. Если регистр не периодический, то он скорее всего очистится полностью.
6.Активизаровать движения документов корректировки записей регистров обработкой «СверткаБазы.epf». При этом обработка эти документы переносит на предыдущую дату (это удобно для сверки остатков в двух базах).
7.Перерасчитать итоги
8.Проверить корректность ввода остатков и исправить (для этой цели можно привлечь сотрудников бухгалтерии)
9.Перенести документы из рабочей базы в новую базу. Эту процедуру можно делать уже сразу после создания копии. Т.е. если ежедневно в базе создается много документов, то перенос документов лучше делать параллельно, чтобы дополнительное время на это не тратить.
10.Пустить пользователей в новую базу. Для этого лучше переименовать базы на сервере 1с, чтобы для пользователей переход был безболезненным. Т.е. старую базу называем как угодно а новую (свернутую) базу переименовываем в старую.
Оригинал статьи: http://torosian.ru/work/public_id/?article=522
Примечание!
Как известно, при непосредственном удалении объектов не происходит контроль ссылочной целостности.
Соответственно, после удаления объектов в текущей базе остаются объекты ссылающиеся на несуществующие объекты («Объект не найден»).
У меня задача не стояла, чтобы эти объекты были в свернутой базе. Но битые ссылки могут отрицательно сказаться и на разного рода обмены между базами, и на другие процессы.
По этому я их перенес в свернутую базу, но после того как базу свернул.
1.Сделал правила обмена, которые переносят документы (только номер, дата в непроведенном виде).
2.Перенес все документы которые встречались в документах ввода начальных остатков.
Эту процедуру можно делать после свертки, но желательно инструменты подготовить заранее.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
в целом не понятно чем ты там так долго занимался если создаются доки для хранения стартовой инфы туда закидываются последние срезы по регистрам сведений и накопления м досвидос!!! пытался подобное делать в процессе работы внемономпольном режиме (главное чтобы шев не кричал где мои деньги:)))
В базе такого размера нет смысла удалять документы. Проще (и быстрее) сделать третью (пустую) базу УТ и уже в нее затащить доки остатков (справочники, регистры сведений) из первой базы и оперативные доки из второй базы.
Зачем тратить время? Базы идентичные — можно просто затащить всё (и остатки из одной базы и обороты из другой) с помощью ВыгрузкаЗагрузкаДанныхXML.epf с ИТС или любой из вариаций этой обработки с этого сайта.
На самом деле 1С могла бы прямо в платформе организовать двухступенчатую форму хранения данных — архив и оперативный период. Это дало бы скорость проведения в оперативном периоде (где период можно было бы установить тот который нужен: месяц, 2 и т.д.) и возможность формировать отчеты за любой период — ведь не все могут смириться с невозможностью построить аналитические отчеты сразу за весь период, а не лепить отчет из нескольких.
Можно сделать это самостоятельно в двух базах и обращаться ко второй через COM, но основной косяк будет в том, что все нужные отчеты надо переписывать — это уже затраты как по времени, так и в ден.выражении. Да и скорость формирования будет не та…
(1) создание документов ввода начальных остатков делается относительно быстро, медленнее происходит удаление объектов. и потом 2.5 рабочих для этого процесса совсем немного. Можно разными путями прийти к цели, но наиболее безболезненным я посчитал именно этот. перенос движений в чистую базу не подходит, т.к. корректировка документов в 1С допустима задним числом и такие корректировки, к сожалению, пользователи периодически делают. И отбирать такое право нельзя!
(2) Bujum,
1.Изначально рассматривались разные варианты.
Вариант создания пустой базы и переноса туда остатков и документов сразу отпал по следующей причине:
Нужно было оставить 1.5 года. т.е. нужно было перенести документы за 2 года и их провести. Учитывая то, что часто случайное перепроведение прошлого периода меняет текущие остатки (себестоимость, взаиоморасчеты, валовая прибыль и т.д.), то при таком способе свертки получить корректные остатки на текущий день просто нереально. Т.е. нужно было еще и остатки сводить.
А кто говорит что быстро можно затащить в чистую базу документы за 1.5 года и радоваться результату, тот значит либо этого вообще не делал, либо делал но не с большими базами.
2.Методов для свертки можно придумать много, я сделал таким образом. После недели работы с свернутой базы, результат все еще радует.
(4) comol,
1.Здесь речь не идет об оптимизации на уровне SQL. Задача стояла именно в свертке базы, причины были не только в медленной работе 1С.
2.решений для свертки я почитал много на инфостарте, некоторые варианты пытался применить на тестовой базе. Подходящего решения не нашел, ибо если бы нашел подходящий вариант, то воспользовался бы с удовольствием.
3.Я уже писал, что задача стояла оставить данные за последние 1.5 года. Вариант переноса документов и/или движений в новую базу не подходил.
имхо подобные вещи лучше подавать с учетом 24х7, без остановки производства и т.п. нюансами
просто «сверток» тут много )
(8) Gilev.Vyacheslav, согласен. Я здесь описал скорее частный случай со своими нюансами. Но возможно сама идея кому нибудь еще поможет.
Мне этот метод устраивает еще тем, что сделав один раз инструмент, могу периодически безболезненно свертывать базу.
Весь сыр бор о правильности или не правильности выбранного метода, я считаю от того что 1С глубоко плевать на проблемы пользователей! Это видно уже в том что они не сохранили свою обработку из 8.1 для бухгалтерии 8.2.
Да и их правила перехода с одной конфигурации на другую, сплошной геморрой. Я так и не смог обновить бухгалтерию 2.0.48.9 на бухгалтерию 3.0.21.14(Видите ли появились лишние документы которые не удаляются). Нужно искать причины и способы почему это не работает.
ПОЭТОМУ КАЖДЫЙ ВЫНУЖДЕН СТРОИТЬ СВОЙ ВЕЛОСИПЕД.
Я считаю что автор этой статьи построил то который был ему нужен.
Камни в чужой огород кидать всегда легче, чем самому пахать. И советы давать НУ ТУТ НАМ «РОССИЯНАМ» РАВНЫХ НЕТ.
(10) ZVN, как говорится, в споре рождается истина))) только не всегда комментарии пишутся по существу.
(11) setrak,
<quote>
Остатки формировал типовой обработкой «СверткаБазы.epf».
</quote>
Подскажите где можно найти типовую обработку «СверткаБазы.epf» для Бухгалтерии 8.2
(12) ZVN, Обработку СверткаБазы.epf можно найти на диске ИТС.
Рассматривали такой вариант:
Удалять не весь старый период, а например по одному году в день? Днем запуск обработки для ввода остатков на конец года, ночью удаления документов за год.
(14) Емельянов Алексей, Я пробовал брать небольшой период. т.е. постепенно обрезать до нужного периода. но типовая обработка все равно долго делала. т.е. если сравнить весь объем трудозатрат, то потратил бы намного больше времени.
(15) setrak,
Понял, спасибо.
(8) Gilev.Vyacheslav, согласен что почитать вариант 24х7 было бы интересней, тем более если в виде нюансов выступают постоянные обмены с другими информационными системами (Вячеслав, может вы нам напишите что-то подобное?). Автору нужно было назвать статью не «Как свертывать большую базу …» а «Как я свернул свою большую базу». Тогда глядишь и вопросов было бы меньше. А так велосипед как велосипед.
Чтобы успеть что-то сделать за ночь (или за выходные) можно сворачивать не все регистры накопления сразу, а часть. Сразу же после свертки переносить/активизировать остатки по свернутым регистрам. База останется работоспособной. То же самое по поводу удаления документов.
Всем привет!
А зачем сидеть ночь или сутками над сверткой трепыхать? Не проще ли сначала сделать распределенку, всех туда и пусть спокойно работают, в то время как можно недели 2 посворачивать в спокойном рабочем режиме? Потом загнать простым обменом то, что они наработали в свернутую. Велосипед не нужен, нам бы самокат 🙂
1) Кто говорит, что можно перенести документы в новую базу, ни когда этого не делали на больших объемах.
2) За битые ссылки минус, косяк в sql запросах.