Всем, "обрезавшим" огромные базы 7.7 посвящается...

Исходные даные:
база 7-ки более 12GB с данными за 4 года. УРБД - центр+7 перифериек. Конфига самописная, когда-то на основе типовой "Бухгалтерии".
файл инициализации периферийной базы в архиве - почти 2GB. Не знаю как на 27-м релизе, но до 21-го господа 1С-ники так и не поменяли вшитый zip, поэтому выгрузить данные, которые в итоге в архиве будут весить более более 2GB, не представляется возможным - старый zip не понимает файлы более 2GB. (Поправка - представляется возможным:Плагин romix-a //infostart.ru/projects/1512/)
Как следствие размеров базы - практически невозможно работать: операторы ругаются, всякие манипуляции типа перепроведение / дальнейший обмен по УРБД и т.д. ОООЧЕНЬ трудоёмки (точнее "времяёмки")

Требуется:
в кратчайшие сроки обрезать базу (оставить текущий год)

Испробовано:
все типовые и "не совсем" типовые методы (свертка, пометка на удаление прошлого периода), рокет-ланчеры (и прочие OLE) и т.д. Не испробованы прямые запросы к SQL на удаление, по причине невладения ничем кроме языка 1С.

Основная проблема:
очень долгая пометка на удаление документов прошлого периода (исходное условие задачи - простые юзеры - опера и бухи - не заносят новые остатки в "пустую" базу ручками, обеспечение "преемственности" периодов - если поправили что-то в обрезанном периоде - изменения должны отразиться в рабочем периоде)

Решение:
1). создаем документ в конфиге, который при проведении будет писать за собой проводки и движения по регистрам (если требуется - по заданному фильтру), рассчитанные на "сам себя": т.е. после проведения такого дока (проводится на дату обрезки) имеем в базе на дату этого дока "удвоенные" остатки по бух. счетам и регистрам остатков.

2). берем копию исходной базы, оставляя в ней все справочники (без DH, DT, RA, RG, 1Cxx). Так же остаются файлы УРБД, кроме 1CUPDTS (совсем забыл - фишка метода - УРБД! Если база нераспределенная - придется распределить))).

3). в "старой" базе проводим наш чудо-документ (у меня он называется "Архив"). Делаем выгрузку в периф. базу из "старой" таким образом, чтобы выгрузился ТОЛЬКО НАШ "АРХИВ" (просто убиваем перед проведением "Архива" 1SUPDTS.DBF и CDX)

4). путем несложных манипуляций с файлом обмена УРБД превращаем его из "исходящего" во "входящий" для центра (меняем заголовок, счетчики, "Acknowledgements". Структура файла обмена здесь: http://oksla.narod.ru/urib.htm , менять надо основное содержимое файла DAT во "входящем" файле для новой базы, который изначально берем из "входящего" файла любой периферийки из старой базы

5). Памятуя о том, что копия нашей "новой" базы - это "клон" "старой", грузим в "новую" базу сей подкорректированный уже "входящий" файл обмена. Вуаля - в итоге в новой базе имеем документ "Архив", со всеми проводками и движениями регистров, которые формируют остатки на дату "Х". Один минус - ссылки в проводках и движениях регистров на документы обрезаемого периода выглядят как (со ссылками на справочники, константы и перечисления все в порядке - в "новую" базу в п. 2) мы не взяли только документы и движения по ним)- нас сие не устраивает, поэтому см. пункт 6).

6). для документа "Архив" пишем обработку (она у меня - в самом документе на кнопке его формы висит), которая, перебрав все движения дока "Архив"(проводки и регистры), "проинициализирует" все ссылки (документы и, если надо, справочники) из движений (тупо "Записать()"). Эту операцию делаем ОПЯТЬ ЖЕ ПРЕДВАРИТЕЛЬНО УДАЛИВ 1SUPDTS - чтобы в выгрузке у нас оказалось ТОЛЬКО ТО, ЧТО НАМ НУЖНО!

7). смотрим и повторяем пунк 4). и 5). - с итоге имеем в "новой" базе "восстановленные" документы, на которые ссылается наш "Архив". Идея проста - при обмене УРБД, если базе подсовывают док (справочник), который в ней отсутствует (был удален, даже совсем)- 1С его ВОССТАНАВЛИВАЕТ. Минус - "восстановленные" доки будут проведенными - в "старой"-то базе они проведены! а в "новой" базе они нужны помеченные на удаление - просто как ссылки "остатков". Но теперь пометить эти доки на удаление занимает не 3-4-5... суток (я так и не дождался окончания "эксперимента"), как на "полной" базе, а от 2 минут до 1 часа (в зависимости от размеров аналитики остатков). Другое решение - при выполнении пункта 4). эти доки перед загрузкой "пометить" в "утробе", чтобы они с обменом УРБД "приехали" уже помеченными - это еще не реализовано за неимением времени - надо основательней поковырять структуру DAT-файла обмена.

8). документы за текущий период так же переносим в "новую" базу через обмен УРБД, проинициализировав (Записать()) документы за нужный период. Перепроведение доков текущего периода - не обязательно. Если в точке "обрезки" с остатками все впорядке - перепроводить не надо, т.к. доки в текущем периоде с Обменом приедут из старой базы СО ВСЕМИ СВОИМИ ДВИЖЕНИЯМИ, а "Архив" притащит как раз ССЫЛКИ НА ЭТИ ДВИЖЕНИЯ.

Ну вот вкратце метод - РЕАЛЬНО ОПРОБОВАННЫЙ (база "порезана" в августе 2007-го, на сегодня полет нормальный).
P.S.
про "преемственность" - если меняем что-то в "старой" базе - перепроводим "Архив" и снова грузим его через УРБД в "новую".
Здесь есть АКТУАЛЬНАЯ проблема: при одновременном создании документов и справочников в обеих базах ID объектов "двоятся" и при обмене "затираются".

 

 

 

P.P.P.S.
На SQL все так же работает на ура - проверено 20.04.08- разрезал базу размером почти 20Гб с 7-мью периферийками, на все-про-все ушло 7 часов.
Еще момент: если режем центральную с периферийными - чтобы потом быстро выгрузить новые периф. базы, достаточно в таблице _1SDBSET значение "C" поля "DBSTATUS" сменить на "N",
чтобы осуществить первичную выгрузку в периферийные с ТЕМИ ЖЕ идентификаторами. Старые идентификаторы позволят подгрузить уже в новую базу обмены с перифериек, если,
например, нет возможностью заменить базы "разом" во всех подразделениях.