Свертка версий объектов

Обработки - Свертка базы

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

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

Скачать файлы

	Наименование	Файл	Версия	Размер
	Файл обработки .epf 7,62Kb 30.11.09 253	.epf		7,62Kb	253	Скачать

См. также

Корректировка остатков регистров накопления (обычные и управляемые формы)

Очистка регистров накопления, сведений, расчета или бухгалтерии

Свертка БП 2.0 документами Ввод начальных остатков

Свертка 60, Свертка 62, Исправление ошибок взаиморасчетов, Исправление 60, Исправление 62

Универсальная консоль SQL + Свертка базы

Свертка базы 1С:Бухгалтерия 2.0

Простая свертка базы данных Управление торговлей 10.3

[БП 3.0] Свертка БП 2.0 или БП 3.0 документами "Ввод начальных остатков" в БП 3.0 beta

Свертывание объемной базы средствами SQL

Универсальная свертка БД

Альтернативный контроль помеченных и быстрое удаление средствами SQL

Корректный перенос остатков из другой базы через COM

Свертка базы УТ 11

Свертка цен (для УТ и УПП)

Универсальная свертка регистров

Ещё один вариант свертки регистров учета НДФЛ (для ЗБУ/ЗКОУ/ЗКМУ ред. 1, ЗУП ред. 2.5)

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

Правила обмена для свертки БП 3.0 -> БП 3.0 (3.0.43.241) , БП 2.0 -> БП 2.0 (2.0.64.33) документами ВводНачальныхОстатков / Ночной перенос остатков

Перенос остатков или способ уменьшить размер базы

Свёртка базы

Комментарии

6. mrApachik 36 30.11.09 18:21 Сейчас в теме

(2) На базе 1 милион записей запрос выполнился на дохлом ноутбуке в течении 10 сек. :), из базы тянуться только ссылки, что не затратно. На действительно больших объемах конечно есть смысл оптимизировать, и выбирать объекты пачками, а не одним запросом. Вытянув ссылки на весь милион объектов клиентская 1Ска в процессах занимала 300 мб оперативной памяти... Поэтому не возникало задачи, что то оптимизировать, но в близжайшее время как раз займусь этим, т.к. база в скором времени планирует увеличиваться...

(3) В этом случае, возникают блокировки :(

(4) Идет внедрение, поэтому от таких ситуаций, пока не избавится :)

(5) Спасибо, будем думать над развитием.

7. ZyMik 02.12.09 11:43 Сейчас в теме

Автору: Поясните понятие "Лишние записи"? Это записи, не хранящие изменений в самом объекте?

8. mrApachik 36 02.12.09 14:18 Сейчас в теме

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

Пример:
Открываем любой документ, для которого в настройках версионирования стоит "Версионировать". 5 раз нажимаем кнопку "Записать", открываем историю изменения объектов и смотрим. Появилось 5 новых версий. Если посмотреть отчет по изменениям этих версий, он покажет что версии идентичны. Соответственно - эти записи нам не нужны...

11. mrApachik 36 03.12.09 12:43 Сейчас в теме

(9) Вот вот :) Хорошо бы всё таки организовать проверку версий в реальном времени при записи объектов, но честно говоря как это реализовать с незначительной потерей производительности и отсутсвием конфликтов блокировок, пока не знаю...

(10) Записей будет столько, сколько раз будут записывать версионируемые объекты (изначально 0). А насчет SQL... Моё мнение: если потребность в переходе на SQL выше, чем его стоимость, то конечно стоит!

10. hanio 46 02.12.09 22:04 Сейчас в теме

Хочу с нового года включить версионирование но тут вопрос у меня УПП узе 1.4 Гб в файловом варианте, подскажите сколько на вскидку юедет записей и стоит ли перелазить в SQL?

14. mrApachik 36 03.12.09 14:14 Сейчас в теме

Эта схема уже работает на реальной базе? Я думаю, что будут ощутимые потери производительности. Сначала нужно получить версию текущего объекта, записать её на диск (т.к. сейчас при версионировании используются объекты, которые не умеют работать в памяти), что по потери скорости уже практически равно созданию обычной новой версии. Потом получить предыдущую версию, проверить не сжата ли она фоновым заданием, если сжата, то "расжимаем".
И только тогда сравниваем версии... В большинстве случаев это очень неэффективно.
В версионировании узкое место - это жесткий диск, если все операции выполнять в памяти, думаю можно в разы ускорить работу. Для этого можно попробовать писать в ХранилищеЗначения не ДвоичныеДанные, а например внутреннее строковое представление объекта. Правда не знаю, насколько это оправдано. Нужно проверять...

15. WKBAPKA 193 03.12.09 23:40 Сейчас в теме

просветите плж., что это за подсистема такая?

16. iceflash 4 04.12.09 16:21 Сейчас в теме

Автор видимо имеет ввиду стандартное решение от 1С в типовой конфигурации, например тут есть выгруженная подсистема http://infostart.ru/public/61706/

17. Wolfis 4 24.03.10 10:10 Сейчас в теме

Возможно ли сделать сначало бэкап объектов а затем их уже чистить???

18. ZyMik 27.04.10 07:05 Сейчас в теме

У меня не может прошерстить 78 тыс объектов. вылетает. Объем памяти распухает до 1.5 гиров и трындец. Нужно не держать все в памяти, а делить на порции.

19. sevipa 10.09.11 01:07 Сейчас в теме

вылетает с ошибкой "не хватает памяти"

20. SkorikA 82 14.12.11 06:54 Сейчас в теме

Спасибо:) Работает. Регистр почти в 5 миллионов записей удалось сократить на треть. В качестве пожелания разработчику: если бы еще бы можно было настраивать отборы (например документы за определенный месяц) чтобы была возможность запускать обработку частями - было бы вообще идеально. А то в том случае, когда количество обрабатываемых документов приближается к паре миллионов дело может затянуться:)