Нужны идеи по свертке базы. КА, РИБ 12ть баз, ЦБ 254 Гб SQL. #710888

Всем доброго утра. Появилась задача от старого хорошего клиента по свертке базы КА. Как видно из заголовка, в РИБ обмене 12ть баз, среди которых половина супермаркеты, половина оптовые базы.  В день в базе появляется ~ 2500 документов. Желательно свернуть на начало года, или на край на конец первого квартала. История базы начинается с 2010 года. Видим 2 варианта. 1) Свернуть базу на 31.12.2013 и удалить старые документы. 2) Свернуть на 31.21.2013 и перенести документы ввода остатков и документы за 2014 год в чистую базу обработкой ВыгрузкаЗагрузкаДанныхXML.epf Хотелось бы услышать мнение тех, кто подобные задачи решал. Какой из этих вариантов более жизненный? Может предложите другой вариант? Спасибо!

может поможет

Сначала замерь время свертки базы такого объема. Типовыми средствами будет непозволительно долго. Нетиповыми - за день свернешь.

Сверка - формирование документов "корректировка записей" регистров проходит за 20 минут. И это нормально. В каждом документе по 5000 строк и таких документов 170 шт. При этом выгрузка одного такого документа в XML занимает минут 30 и вес у него получается 20 гб. Думаю такой способ переноса вообще не вариант. Что скажете?

А ты теперь удалить старые документы попробуй.

Хотя бы движения.

это история на долгие года. поэтому этот вариант даже не рассматриваю. может предложите вариант удаления через SQL? Где то видел скрипт, который может удалить все документы до определенной даты, и записи в регистрах. Может кто владеет языком SQL запросов?

Почистить регистры - дело нехитрое. Главный вопрос после свертке РИБ - сможешь ты потом корректно создать новые переферийки из свернутой базы?

после такой очистки нужно обязательно делать ТИИ иначе в базе останется куча кривых ссылок. А есть скрипт очистки регистров и документов?

Откуда кривые ссылки возьмутся? (в аську стучись)

если все базы - sql c совпадающей внутренней структурой таблиц напишите tsq скрипт, который создаст документы остатков удалит движения , удалит документы и возможно удалить не используемую номенклатуру.

ЦБ и перефирийки можно ведь отдельно свернуть. В обмене тоже все просто. Можно передать вначале просто документы, потом по каждому документу - свои движения, причем передавать можно только ссылки а не тянуть все объекты.

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

перефирийки у тебя тоже на СКЛ?

языком SQL не владею, поэтому тут и интересуюсь. Мне бы образец скрипта, а дальше я бы сам его по смыслу допилил.

конечно же все периферийки в SQL. я планировал свернуть только ЦБ, а потом постепенно разворачивать новые периферийки и заменять ими старые.

"В обмене тоже все просто. Можно передать вначале просто документы, потом по каждому документу - свои движения, причем передавать можно только ссылки а не тянуть все объекты." вы это про что? про то как свернуть все периферейки? я думал их заменить.

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

с заменой перефириек могут возникнуть проблемы

сейчас обмен идет без проблема. качаем 2 раза в день через ftp. Меня вопрос замены периферийных баз вообще не напрягает, т.к. иногда базы валятся и их восстановление процедура отлаженная. Не охото сейчас на это тратить время. Сейчас задача основная как свернуть ЦБ?   С переносом в новую или с удалением в старой.

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

У меня была немного похожая задача. УТ 10.3 в терминале в 8 городах. Примерно 1800 заказов в день. Начало базы с 2008 года. Для свертки я применил новую периферийную базу. При ее создании перенес все кроме документов и их движений. Подключил документы с движениями. В старой базе создал документы свертки на конец прошлого года без проведения. Перенес документы свертки и документы этого года с движениями. Провел документы свертки в новой базе. В старую ответ не выгружал. Стали работать с новой базой. Через пару недель после тестирования сделал ее главной. Пользователей с правами перенес обработкой взятой с интернета.

Интересная идея. Только подскажите как создать новую РИБ базу без переноса документов и движений? При нажатии в планах обмена на кнопку "Создать начальный образ" все происходит в автомате, и база создается и документы в нее заливаются.

вы все про периферийки да про периферийки :) а как ЦБ свернуть не предлагаете :)

на ИС есть готовая обработка по свертке баз средствами Sql я сам два раза ей сворачивал базы по 80 ГБ достаточно шустро и  почти без косяков

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

+1 Есть результаты анализа размеров таблиц и индексов? Для 2500 док/день 254Гб многовато получается.

Берешь полный план обмена в конфигураторе. Или копируешь его со своим названием, чтобы не повредить текущие обмены с другими периферийными базами. И  в закладке прочее в составе этого обмена убираешь галки на документах и регистрах. Можно иначе используя процедуру Процедура ПриОтправкеДанныхПодчиненному(ЭлементДанных, ОтправкаЭлемента, СозданиеНачальногоОбраза)

Процедура в модуле обмена.

функция обОтправлятьОбъектВУзел(ЭлементДанных) для образца, но она не идеальна только как пример.

Если будешь так сворачивать могу одну обработку для отметки выгрузки документов с его движениями выслать на почту.

Периферийную базу центральной легко сделать. У неё в свою очередь тоже свои периферийные базы могут быть. Плюс тут в том, что тестировать обрезанную базу можно не прерывая работу с центральной. В последний момент догружаешь текущие изменения и делаешь центральной. Или что-нибудь догрузить можно пока связь не оборвал.

Примерно алгоритм такой: 1. Создаем документы корректировки с неактивными движениями. 2. отключаем итоги 3. удаляем движения через скуль 4. включаем корректировки и итоги И так на каждой базе Удаление документов конечно более сложная операция

Плюсы  - можно последовательно удалять разные регистры

У меня есть такая обработка - могу продать

план действий понятен. как удалить скулем движения?

буду презнателен. почта SemenovPV@yandex.ru