Опыт свертки базы 1С:ERP

14.03.17

База данных - Свертка базы

Свертка информационной базы 1С – процесс обработки документов и регистров конфигурации, позволяющий удалить старые, ненужные документы. Вместо них формируется несколько документов ввода остатков на заданный период. Таким образом мы “обрезаем” ведение учета до заданного периода.

В процессе работы информационной базы ее размер неминуемо увеличивается. В крупных компаниям он может достигать от 5 Гигабайт в год и более. Такой стремительный рост может сказываться как на быстродействии программы, так и на сохранности данных. Чем больше размер информационной базы, тем более вероятны сбои, влекущие за собой потерю данных.

Как очистить информационную базу 1С, сохранив всю необходимую информацию?

В этом вопросе поможет “свертка информационной базы 1С” – процесс обработки документов и регистров конфигурации, позволяющий удалить старые, ненужные документы. Вместо них формируется несколько документов ввода остатков на заданный период. Таким образом мы “обрезаем” ведение учета до заданного периода.

Основными целями свертки являются:

  • Увеличение скорости работы системы

  • Уменьшение размера информационной базы

О свертке стоит задуматься,  если:

  • “тормозит” 1С

  • Большой размер базы 1С (от 5 Гигабайт и более)

  • Долго выполняется обновление 1С

  • “Мозолят” глаза документы прошлых лет

В рамках проекта передо мной встала задача: Как свернуть базу 1С при переходе с 1С:ERP 2.0 на 1C:ERP 2.1?

На момент необходимости свертки фирма 1С разработала штатные механизмы только для 1С:УТ 11 и 1С:БП 3.0, а также для более старых версий.

Для разработки свертки я взял за основу механизм из 1С:УТ 11. Релиз 1С:УТ 11 брал приблизительно того же времени выпуска, что и 1С: ERP 2.0. 

Этапы свертки базы 1С

Свертка информационной базы осуществляется в три этапа:

  • ввод остатков

  • удаление данных прошлых периодов (удаление движений и пометка на удаление документов)

  • сверка остатков с рабочей базой

Ввод остатков

Для ввода остатков в любой конфигурации предусмотрены специальные документы.

Конфигурация 1С:ERP является симбиозом нескольких подсистем. Для каждой подсистемы используются свои документы ввода начальных остатков.

Для части документов ввода остатков в 1С:УТ 11 предусмотрены процедуры автоматического заполнения остатками по регистрам.

Например, “товары на складах”, “взаиморасчеты с клиентами/поставщиками”, “заказы клиента/поставщику”, “возвратная тара”, “денежные средств”)

Для других документов необходимо разрабатывать свои процедуры.

Например, “расчеты с сотрудниками”, частично по регистрам бухгалтерии, кадровому учету, Внеоборотные активы.  

Перед переносом остатков нужно провести анализ: какие данные исходной базы подлежат переносу. Для того, чтобы ничего не упустить при разработке, я определил, по каким регистрам накопления, бухгалтерии и сведений есть остатки (данные) в базе-источнике на дату ввода - разработал отчет по остаткам и движениям по всем регистрам накопления, сведений, бухгалтерии. 

  • Заполнение документов «Ввод начальных остатков»

По каждому виду операции ввода остатков я провел анализ на существование механизма ввода остатков в обработке из 1С:УТ 11, определил, какие регистры двигают данный вид операции. Для несуществующих механизмов ввода остатков разработал собственные. 

  • Заполнение документов “Корректировка регистров”, “Перенос данных” и “Операция(регламентированный учет)”

После разработки ввода остатков стандартными документами выяснилось, что для некоторых подсистем, механизмов, регистров нет соответствующих документов ввода остатков.

Например, остатков на производственных регистрах, “прочие активы и пассивы”, “заказы на перемещение”, “распоряжения на выпуск”, “расчеты с фондами по страховым взносам”.

Можно доработать конфигурацию для ввода остатков по таким регистрам (механизмам) или разработать заполнение остатков с помощью документов:

  • “Перенос данных” - подходит для регистров подсистем расчета зарплаты и управления кадрами

  • “Операция(регламентированный учет)” - подходит для остатков на регистрах бухгалтерии по тем данным, которые не отразились документами “Ввода остатков”

  • “Корректировка регистров” - подходит для остальных подсистем.
  • Сложные схемы ввода остатков 

Для некоторых механизмов 1С:ERP нельзя ограничиться внесением остатков на дату свертки. Это обусловлено тем, что для определенных механизмов ключевые данные хранятся не только в регистрах, но и в самих документах. В основном это документы, на которые ссылаются данные регистров. В стандартной обработке ввода остатков такой механизм разработан для учета заказов покупателя. Суть его заключается в следующем:

1. Берутся остатки по незакрытым остаткам заказов

2. Документы из остатков помечаются специальным комментарием

3. Для частично не закрытых заказов табличная часть перезаполняется только данными остатков на дату свертки

В таком случае у нас не вводятся документы ввода остатков по регистрам механизма заказов, а документы заказа, по которым есть остатки, помечаются специальным комментарием. Такие документы при последующих этапах свертки не удаляются.

Такой же механизм я применил для кадровых документов. Документы сотрудников, работающих на дату свертки, пометил специальным комментарием, остальные документы были удалены на последующих этапах свертки.

Удаление данных прошлых периодов

Удаление данных производится в два этапа:

  • удаление движений документов

  • пометка документов на удаление

При удалении движений по каждому регистру:

1. Выбираются все документы, которые:

  • “двигали” регистр до даты свертки

  • не содержат специальные комментарии, оставленные на предыдущем этапе

2. Отключается использование итогов

3. Для каждого документа удаляются движения

Для каждого вида документов формируется список документов, не содержащих специальный комментарий. На них ставится пометка на удаление. 

Сверка правильности ввода остатков с рабочей базой

Сначала проверяются остатки в целом по каждому регистру, по всем ресурсам (без детализации по измерениям). Если итоговая сумма каждого ресурса совпадает, то проверяем следующий регистр. Если есть разница, то  анализируем более детальные остатки в разрезе измерений. Начинать необходимо с измерений, имеющих наименьшее количество разных значений.

Например, для большинства регистров первым анализируется измерение Организации. Выявляется, по каким организациям есть расхождения. Далее для каждой организации анализируются более детальные данные.

Если такие сложные системы как 1С:ERP, 1С:УПП, 1С:Комплексная автоматизация, 1С:Управление холдингом используются в большей степени для решения бухгалтерского учета, то возможно неполное или частично неправильное использование некоторого функционала программы. Это происходит из-за того, что сотрудники бухгалтерской службы производят контроль по регистрам бухгалтерии, выполняя ручные корректировки документами Операция(регламентированный учет) и не контролируют данные в соответствующих регистрах накопления.

В 1С:ERP основой для операций бухгалтерского учета являются регистры накопления. Операции формирования документов ввода остатков выполняются на основании данных регистров накопления.

В этой ситуации остатки, введенные сверткой базы по данным регистров накопления, по регистрам бухгалтерии будут различаться между новой и рабочей базой.

Существует два варианта решения проблемы:

1. В рабочей базе привести остатки по регистрам накопления в порядок

2. Переписать процедуры ввода остатков с данных регистров накопления на данные регистров бухгалтерии (если данные в регистрах бухгалтерии покрывают данные в регистрах накопления). Я использовал второй способ. 

Организация процесса свертки данных

Для орагнизации свертки информационной базы обычно создается отдельная ее копия и в ней запускается обработка, которая выполняет операции, описанные выше. Копия базы делается для того чтобы сохранить в отдельной базе старые данные, а в новой свернутой базе продолжить работу.

Все было бы просто, если бы не большое время выполнения обработки – от нескольких часов до нескольких недель.

Длительность процесса свертки зависит от:

  • конфигурации базы

  • используемых подсистем

  • объема внесенных данных до даты свертки

Из-за длительности процесса возникают две существенные проблемы:

1. Двойная нагрузка на пользователей. Пока не будет готова новая свернутая база, необходимо продолжать учет: выписывать документы, расчитывать и фиксировать измененные данные, сдавать отчетность. После создания новой свернутой базы пользователям необходимо в новой базе внести всю информацию, которая вносилась в старую во время процесса свертки и параллельно вносить новые данные, т.е. выполнять текущую работу . Кроме того еще надо сверить в новой остатки и проверить работу системы после внесения остатков, т.к. могут быть скрытые ошибки свертки базы.

2. Сложность тестирования обработки свертки. На этапе разработки методологии свертки или написания кода обработки возрастает цена ошибки. Если, например, процесс свертки занимает 1 день, то процесс тестирования при 10 ошибках может занять 10 дней, если каждая ошибка выявлялась не сразу, а после каждого нового тестирования. А если свертка занимает не 1 день, а неделю? А если не 10 ошибок, а больше?...

Для решения этих проблем я использовал план обмена и обработку “Выгрузка и загрузка данных XML”.

В рабочей базе я добавил план обмена, фиксирующий все изменения после создания копии базы для свертки. После свертки измененные данные в рабочей базе переносил обработкой “Выгрузка и загрузка данных XML”. Таким образом пользователям не пришлось вносить данные в Новую базу, они были перенесены автоматически.

Выявление  ошибок написания кода обычно происходит на этапе сверки остатков, т.е. после введения остатков и удаления данных прошлых периодов. Так как этап удаления довольно длительный, а правильность введения остатков в большинстве случаев не зависит от этапа удаления, то практичнее тестирование и доработку ввода остатков делать в отдельной третьей базе. Пока в Новой базе проходил процесс удаления данных прошлых периодов, я устранял выявленные ошибки в обработке свертки и дорабатывал новые процедуры свертки. После окончания удаления старых документов и движений у меня была готова Новая база, но с неправильными остатками. На отдельной копии рабочей базы я формировал документы остатков, изменения автоматически фиксировались в плане обмена, и обработкой “Выгрузка и загрузка данных XML” переносил измененные остатки в Новую рабочую базу. При выявлении новых ошибок – повторял эти операции. Данный метод значительно ускорил разработку и тестирование процедур ввода остатков.

Советы из личного опыта по свертке базы 1С:ERP

База клиента содержала 1,5 млн. документов в прошлом периоде.

Длительность операций составляла:

1 час – ввод остатков

6 суток – удаление движений

4 суток – установка пометок удаления

Так как процесс разработки довольно трудоемкий, а продолжительность выполнения этапов свертки велика, то на будущее я определил для себя следующую последовательность действий:

1. Добавление в рабочей базе плана обмена.

2. Создание копии базы – «новая свернутая база»

3. Запуск в свернутой базе процедуры удаления всех данных до даты свертки (самая длительная операция)

4. Анализ остатков и разработка операций ввода остатков

5. Формирование в отдельной копии процедуры ввода остатков (с регистрацией изменений в плане обмена)

6. Перенос данных ввода остатков из копии рабочей в «новую свернутую базу»

7. Проверка остатков, при необходимости повторение пунктов 5,6,7.

Сложно с первого, да и со второго раза написать идеальную обработку свертки базы для 1С:ERP, необходимо досконально знать изнутри каждый механизм, каждую подсистему, но с каждым разом будет получаться все лучше и лучше.

#1С: ERP #1С: УТ #Свертка базы

См. также

Оптимизированная свертка Бухгалтерии 3.0

Свертка базы Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Платные (руб)

Расширение позволяет за 1-2 дня свернуть базу с десятками миллионов документов. Использует оптимизированный алгоритм определения документов, на которые нет ссылок, для последующего удаления 16 фоновыми заданиями. Не помечает документы на удаление.

38400 руб.

08.02.2024    480    7    0    

2

Многофункциональная выгрузка из 1С:УТ 11/ УТ 10 в 1С:БП2, БП3 (соответствия товаров, контрагентов, складов, статей ДДС)+Свёртка по НДС

Обмен между базами 1C Оптовая торговля Свертка базы Платформа 1С v8.3 1С:Бухгалтерия 2.0 1С:Управление торговлей 10 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Хотите точно знать, что вы выгружаете? Хотите сворачивать товары по НДС или фильтровать товары по доп. реквизиту? Вы волшебник, которому необходимо превращать одних контрагентов в других? Хотите при выгрузке превратить группу товаров в один? Или просто нужен удобный OLE обмен между 1C:Управление торговлей (ред. 11 или 10) и 1С:Бухгалтерия предприятия (ред. 2 или 3). Тогда эта обработка для вас!

10900 руб.

19.04.2013    168416    350    395    

327

Обрезание базы 1С

Свертка базы 8.3.8 Конфигурации 1cv8 Россия Управленческий учет Платные (руб)

Механизм обрезания базы 1С. Описан процесс переноса среза остатков в копию базы. Представлено прикладное решение - обработка по переносу данных. Реализован способ обмена между базами без длительного отключения рабочей базы.

7200 руб.

27.03.2023    4166    11    2    

13

Сравнение остатков по регистрам накопления

Свертка базы Платформа 1С v8.3 1С:Управление торговлей 10 Управленческий учет Абонемент ($m)

Внешняя обработка (для конфигураций на обычных формах) сравнивает остатки на дату и в разрезе организации по всем регистрам накопления. Сравнение происходит между базами по технологии Com-соединение. Используется при свертке базы.

3 стартмани

вчера в 15:30    309    0    RustIG    0    

2

Свертка остатков по 41 счету в корреспонденции с 91 счетом

Свертка базы Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Абонемент ($m)

Обработка обращается к остаткам по счету 41.1 на дату, что выбрал пользователь, пробегается по ним и заполняет документ "Операция, введенная вручную".

1 стартмани

18.03.2024    208    4    config    3    

2

Свертка ЗУП 3.1 и ЗКГУ 3.1

Свертка базы Платформа 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Абонемент ($m)

Вопрос, который мучает всех: в связи с развитием возможностей программ 1С размеры/объем очень быстро растут (уже объем пустой базы более 1 Гб) и не секрет, что чем "тяжелее" база, тем она медленнее работает. Для БП-3.0 разработчики 1С сделали вшитый типовой механизм свертки базы, суть которого вывести остатки по счетам на дату свертки и удалить все документы/движения до этой даты. А вот для ЗУП пока ничего подобного нет, а база растет быстрее, чем на дрожжах. Я долго анализировал и искал возможные решения для свертки ЗУП, поиск в интернете дал кучу различных вариантов. А когда начинаешь их рассматривать, в основном – только "перенос" среднего заработка, а остальное – "доделай сам". Только фирмы-франчайзи предлагают что-то более серьезное, но за хорошую плату.

5 стартмани

28.02.2024    1015    34    ivnik    16    

16

Свертка выбранных остатков

Свертка базы Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Абонемент ($m)

Обработка позволяет свернуть выбранные остатки по счету на выбранный счет.

1 стартмани

13.02.2024    219    3    medm    0    

3

Свертка ЗУП 3

Свертка базы Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Россия Абонемент ($m)

Свертка ЗУП 3.1 по трем регистрам с возможностью чистки базы от документов движения и чистки сотрудников от уволенных.

5 стартмани

16.01.2024    1163    32    AlexHelmer    1    

6
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Anton_BooR 4 15.03.17 08:48 Сейчас в теме
"Большой размер базы 1С (от 5 Гигабайт и более)"

Мне кажется вы имели ввиду большой размер выгрузки базы.
dsv_nsk; Алексей_mir2mb; +2 Ответить
2. curdate 50 15.03.17 18:45 Сейчас в теме
10 суток на удаление... Ужас.
Совсем недавно сворачивал 120 гб базу... Вся свертка, с учетом времени на бакапы и проверку, заняла порядка 3 часов.
4. СергейК 51 24.03.17 16:39 Сейчас в теме
(2) Фантастическое время, расскажите подробнее!
8. curdate 50 29.03.17 13:44 Сейчас в теме
(4)
Прямые запросы же. Хоть так делать и нельзя - лиц. соглашение, и все такое.
9. СергейК 51 30.03.17 09:23 Сейчас в теме
(8) Андрей, если под рукой есть ссылка на описание вашего метода, поделитесь плз.
10. curdate 50 30.03.17 10:30 Сейчас в теме
(9)
Ссылок нет - методика самодельная. Сворачивать-обрезать можно по разному, нюансы у каждого случая свои. Поэтому адаптирую под заказчиков.
Fox-trot; +1 Ответить
18. RustIG 1351 04.04.19 22:33 Сейчас в теме
(9) делюсь своим опытом https://infostart.ru/public/1033813/
"3 часа для свертки" - это когда полгода ее испытываешь, экспериментируешь, оттачиваешь процесс, а затем из года в год прогоняешь одну и ту же базу. мое мнение!
(10) "Адаптация под заказчиков" занимает много времени, а вот свертка наверное да..... всего три часа.....
велкам ту май паблик пост
Fox-trot; +1 Ответить
21. Greek26rusa 2 27.11.19 16:24 Сейчас в теме
(2)Каким средствами сворачивали?
3. sunflower40 17.03.17 12:54 Сейчас в теме
Да, когда 120 Г достигает, пора сворачивать... Базы работают 7х24... Так что свертка занимает 5 минут - спокойно регистрируется узел обмена, запускается копия с пользователями и справочниками, выгружаются в xml остатки на дату из закрытого периода, из них автоматом формируется ввод начальных остатков... Собственно говоря, все, пользователям надо только сменить ярлычок для запуска новой ИБ.
Alligator48; dgv7dgv; acanta; curdate; +4 Ответить
5. СергейК 51 24.03.17 16:41 Сейчас в теме
(3) Я правильно понял, что вы формируете новую базу с нач. остатками без оставления 2-3 последних лет?
27. sunflower40 29.05.20 21:00 Сейчас в теме
Да. Дату можно выбирать любую, удобнее начало года.
7. curdate 50 29.03.17 13:42 Сейчас в теме
(3)
Это будет работать, если вы обрезаете базу на текущий момент. Тогда да - перебросили остатки, и готово.
На практике же момент свертки находится в прошлом на несколько месяцев, а то и лет. Вот сейчас могут быть свертки на 31.12.2016, или даже 31.12.2015. Перебрасывать через обмены три месяца, или целых 15 - будет еще дольше, чем обрезать.
12. sunflower40 05.04.17 20:52 Сейчас в теме
(7)
1. 120 G - это не показатель объема базы в том смысле, что она будет тормозить... Не дождетесь (Если SQL). Причина в другом - при больших объемах время восстановления при авариях возрастает. Операции тестирования и исправления, или перемещения БД на другой сервер становятся неприемлемо долгими (файловых это тоже касается).
2. "Перебрасывать через обмены три месяца, или целых 15 - будет еще дольше, чем обрезать." -
2.1 Обмен используется не типовой, самописный, работает на порядок быстрее. Простые команды записи и чтения XML, выгружаются только нужные поля (если базы неидентичны)
2.2 Обмен происходит в фоновом режиме порциями с регулируемой нагрузкой - пользователи могут и не замечать.
3. "Фантастическое время, расскажите подробнее! " - Все очень просто (когда уже все это выстрадал...)
3.1 Узел обмена регистрируется - по нему фиксируются новые или измененные объекты, чтоб ничего не упустить. В узле указывается ДатаНачалаОбмена - выбираем в закрытом периоде.
3.2 Создается копия текущей ИБ, в ней в конфигураторе удаляется все, кроме справочников и пользователей (их иногда бывает много). Затем записывается cf из старой ИБ. Это намного быстрее, чем удалять документы или их движения, проще в конфигураторе грохнуть.
3.2 Между новой и старой запускается обмен.
3.3 Из старой в новую заранее написанными обработками выгружаются остатки (по складам, взаиморасчетов с контрагентами, или для Бух - остатки по счетам загружаются в виде документа ВводНачальныхОстатков. Здесь самое интересное - по 01 и 02 счетам конечно же, остальное все типовое, легко делается. Есть варианты, но удобнее всего ручная выгрузка-загрузка через XML.)
3.4 сверка двух баз по складам, взаиморасчетам, счетам и т.д. на ДатуНачалаОбмена - сначала выгружал и сравнивал в экселе или как два файла, потом обработочку написал - из одной ИБ подкл к другой и сравнивает остатки на дату.
3.4 Из старой для новой обработкой регистрируются все документы после ДатыНачалаОбмена.
3.5 Сверка по остаткам на текущий момент.
3.6 Бывает необходимость переноса цен номенклатуры - в старой ИБ обработкой создается документ УчтановкаЦенНоменклатуры на ДатуНачалаОбмена+1 - он автоматом перетекает по обмену в новую ИБ.
3.7 Все пункты выполнялись не торопясь, планово, все спокойно работают, и их теперь можно сажать на новую ИБ - все справочники, остатки, цены и т.д. есть. Вот вроде все, ничего не упустил.
dvissarov5; timurhv; deniskorablev; +3 Ответить
13. СергейК 51 06.04.17 21:42 Сейчас в теме
(12) а что с ИБ п 3.2, для чего она?
подозреваю что из неё делается периферийная для узла обмена из п.3.1 ?
28. sunflower40 29.05.20 21:03 Сейчас в теме
(13) Да. Это новая база с остатками на дату свертки.
14. nickpugachev 06.04.17 22:13 Сейчас в теме
(12)
1. Клиент, купивший конфигурацию за пол миллиона и вваливший еще очень много в ее внедрение найдет денег на холодный резерв с вероятностью 99.999. Отсутствие холодного резерва - скорее признак недальновидности администратора/ит-директора. Но скорее там будет горячий резерв в виде AAG или чего другого в случае не-MSSQL. База 100Гб - это вообще ни о чем.
3.2 пачка truncate table думаю будет значительно быстрее чем просто выгрузка/загрузка cf без остальных телодвижений в любой базе данных кроме файловой (файловая ERP? серьезно?). А также есть секционирование с присоединением/отсоединением секций и тому подобные ухищрения для быстрого сноса/добавления данных
6. СергейК 51 24.03.17 16:48 Сейчас в теме
Оптимизировал вариант удаления докуметов (очистка регистров+пометка на удаление документов)
методом фонового многопоточного (5-7 потоков) запуска на удаления разных регистров/документов. Удалось уменьшить время с 23ч до 6ч.

Хотя метод через выгрузку ХМЛ документов ввода остатков и рабочих документов текущих дней мне понравился (хотя может это и 'боян' и прошлый век в плане новизны)

Хотя, еще есть мнение, что база 100-200 и более Гб не размер, и тормозить не должна если обслуживается правильно и запросы оптимизированы, но меня такой размер пока настораживает.
Клиенты тож хотят избавится в рабочей базе от старых периодов. Пока так.
11. CapShrike 04.04.17 11:13 Сейчас в теме
Добавлю. Была аналогичная задача по свёртке ERP, причём задним числом - смена собственника. В ERP обработка свёртки информационной базы пустая (очищен весь код). Пришлось эту обработку выдёргивать из торговли (пользуясь близостью конфигураций erp и ут11), немного править и уже сворачивать ERP.
15. juliia1992 15.04.18 16:17 Сейчас в теме
Добрый день! Имеется база ERP 2.0, обновленная до текущего релиза. Практически типовая (добавлен 1 регистр сведений и отчет, которые не затрагивают типовую конфу). Объем базы 2 ГБ. Я правильно понимаю, необходимо доработать типовую обработку свертки ИБ (которая есть на ИТС)?
16. shuhard 15.04.18 16:40 Сейчас в теме
(15)
Я правильно понимаю, необходимо доработать типовую обработку свертки ИБ (которая есть на ИТС)

нет, от УТ 11 идентичного с ERP релиза, в самой ERP обработка есть, но без кода =)
17. juliia1992 15.04.18 17:14 Сейчас в теме
(16)
Ясно, спасибо) Так обработка совсем нерабочая
19. mpeg1989 130 04.09.19 17:20 Сейчас в теме
Большой размер базы - от 5 гигов. Сейчас просто DBA в Магните и Деловых линиях кофем подавились!

Если база тормозит при таком размере, значит проблема не в количестве данных, а в качестве их обработки.

Собственно я сюда зашел почитать про свертку, но ее попросили сделать, чтобы убрать из базы те типы документов, которыми уже не пользуются, по сути механизм отмер, а они периодически всплывают при обновлении.
20. user1281209 16.09.19 09:43 Сейчас в теме
Хорошая статья, но вот попалось на глаза такая ссылка на просторах инета насчёт сверки базы данных 1с
Что думаете?
https://1-sys.ru/%D1%81%D0%B2%D0%B5%D1%80%D1%82%D0%BA%D0%B0-%D0%B1%D0%B0%D0%B7%D1%8B-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-1%D1%81/
22. Velifer 22.05.20 17:22 Сейчас в теме
Два месяца назад свернул базу 1С ЕРП размером 250 Гб

Все процедуры свертки заняли 40 минут
Нет битых ссылок, корректные остатки, шринк

Сейчас сворачиваю КА 2 размером 2 Террабайта

Все процедуры свертки заняли 2.2 часа, за искючением шринка
Шринк делали отдельно, занял 3 часа, в отдельное технологическое окно
Также, без битых ссылок, корректные остатки

Использую свою методику

Главное соблюдать стандарты разработки и все получится ;););););););)
24. Fox-trot 156 22.05.20 18:10 Сейчас в теме
а шринк ради чего, только из-за места?
25. Velifer 22.05.20 20:36 Сейчас в теме
(24)Ну да, место

Вообще, базы по нескольким причинам сворачивают, вот типичные

1. Кто то хочет ускорить работу (хотя лучший путь - тюнинг базы), время восстановления из бекапа, регламенты
2. Кто то наделал копий баз и у вас уже не 2 Терабайта, а 12 Терабайт, с копиями. Или больше
3. Иногда хочется почистить мусор от некорректного учета.
Бывает проще ввести остатки и их откорректировать, вместо того, чтобы править тьму документов в прошлом периоде

Я (в том числе) сверткой больших баз занимаюсь с 2013 года, тонких моментов масса
Быстро обрезать таблицы - наименьшая из проблем при свертке
26. Fox-trot 156 22.05.20 20:59 Сейчас в теме
меня именно шринк интересовал и только
23. Velifer 22.05.20 17:54 Сейчас в теме
Хотя вот месяц назад попадалась УТ 11 на небыстром железе, пришлось в 4 потока запускать
Итого, терабайт за 3.5 часа без битья и с корректными итогами
Но это сервер был не очень, можно было быстрее сделать :(
29. Velifer 18.11.21 08:57 Сейчас в теме
Апдейт :)

На этой неделе свернул полностью перепиленную базу на основе УТ (от типовой осталось 20% функционала)

Объем базы был 4.5 Терабайт

Свертка заняла 3.5 часа

С полным сохранением целостности данных, без битья

Через 3.5 часа в базе можно было работать, затем только шринк в отдельном технологическом окне сделали
Больше никаких постобработок.
30. user1300528 13.11.23 20:32 Сейчас в теме
(29) Нужно свернуть базу ЕРП, прошлый период, очень желательно, не перезакрывая последующие. Есть у вас подобные разработки?
31. пользователь 13.11.23 20:40
Сообщение было скрыто модератором.
...
Оставьте свое сообщение