Версионирование объектов. Сжатие регистра "ВерсииОбъектов"

30.12.14

База данных - HighLoad оптимизация

Cжимаем версии объектов в регистре сведений "ВерсииОбъектов".
Экономия занимаемого версиями объектов объема более 50% !!!

Файлы

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование Скачано Купить файл
Сжатие версий объектов (версионирование)
.epf 7,23Kb ver:1.0
49 2 500 руб. Купить

Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний

Оформите подписку на компанию для решения рабочих задач

Оформить подписку и скачать решение со скидкой

Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

Используется для уменьшения занимаемого объема версиями объектов в регистре сведений "ВерсииОбъектов". 

В обработке использован код процедуры "ВыполнитьСжатиеВерсийОбъектовПоРегламентномуЗаданию" из общего модуля "ВерсионированиеОбъектовПривилегированный" типовой конфигурации. Добавлен отбор по периоду обрабатываемых версий.

Внимание: Без использования отбора по периоду возможна ошибка "Недостаточно памяти".

P.S.: Для регулярного использования рекомендуется настроить регламентное задание "СжатиеДанныхВерсионирования".

 

Вступайте в нашу телеграмм-группу Инфостарт

См. также

HighLoad оптимизация Программист 1С 8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Использование оператора «В» для полей или данных составного типа (например, Регистратор) может приводить к неочевидным проблемам.

10.11.2025    7957    ivanov660    48    

53

HighLoad оптимизация Программист 1С:Предприятие 8 1C:ERP Бесплатно (free)

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

18.02.2025    9969    ivanov660    39    

61

HighLoad оптимизация Технологический журнал Системный администратор Программист Бесплатно (free)

Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.

24.06.2024    12523    ivanov660    13    

64

HighLoad оптимизация Программист 1С:Предприятие 8 Бесплатно (free)

Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.

06.06.2024    19027    Evg-Lylyk    73    

46

HighLoad оптимизация Программист 1С:Предприятие 8 1C:Бухгалтерия Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    9296    spyke    29    

54

HighLoad оптимизация Программист 1С:Предприятие 8 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    12884    vasilev2015    22    

47
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. ZLENKO 398 30.12.14 16:44 Сейчас в теме
В одной из баз версии занимали 90 Гб, после сжатия стало 40 Гб. Экономия ощутимая! :-)
2. alexinzaz 30.12.14 23:15 Сейчас в теме
Ну вот хоть убейте не пойму зачем хранить в базе 90гб версий. Грохать к чертовой бабушке. Зачем вам версии десятилетней давности. Это же неактуальная информация.
3. TrinitronOTV 16 31.12.14 07:26 Сейчас в теме
(2) alexinzaz, и как её можно грохнуть?
7. ZLENKO 398 31.12.14 11:42 Сейчас в теме
(3) TrinitronOTV, "и как её можно грохнуть?"

Например вот так (InfoRg12088 заменить на имя таблицы в вашей БД):

            USE testbase;
            GO

            SEL ECT COUNT(*) AS BeforeTruncateCount 
            FROM dbo._InfoRg12088;
            GO

            TRUNCATE TABLE dbo._InfoRg12088;
            GO

            SELECT COUNT(*) AS AfterTruncateCount 
            FR OM dbo._InfoRg12088;
            GO
Показать
eddoptimist; TrinitronOTV; +2 Ответить
4. Virikus 64 31.12.14 10:42 Сейчас в теме
(2) alexinzaz, ну как пример, залез кто-то в период 10 летней давности и поменял количество у документа прихода. Если грохнуть прошлый период, то первой копии версии тоже не будет, соответственно отчет по изменениям ничего не покажет.

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

Хотя если вы привыкли обслуживать только ларьки, то там конечно, такой период версий не нужен.

Другое дело, что блок версионирования лучше переделать на хранение версий в другой базе данных. Хотя бы перенос историй за период регламентным заданием. Вот тогда и база рабочая не растет и история сохранена.
RG-Soft; ZLENKO; +2 Ответить
6. ZLENKO 398 31.12.14 11:37 Сейчас в теме
(4) Virikus, "Другое дело, что блок версионирования лучше переделать на хранение версий в другой базе данных."

Можно переделать чтобы сразу сохраняло упакованную версию:

Процедура ЗаписатьВерсиюОбъекта(знач СсылкаНаОбъект,
                                знач ЧислоВерсийОбъекта = Неопределено,
                                знач ХранилищеДанных) Экспорт
...
	//МенеджерЗаписиИИО.ВерсияОбъекта = ХранилищеДанных;
	МенеджерЗаписиИИО.ВерсияОбъекта = Новый ХранилищеЗначения(ХранилищеДанных, Новый СжатиеДанных(9));
	//МенеджерЗаписиИИО.Сжато         = Ложь;
	МенеджерЗаписиИИО.Сжато         = Истина;
...
Показать
11. TODD22 20 05.01.15 19:20 Сейчас в теме
(4) Virikus,
ну как пример, залез кто-то в период 10 летней давности и поменял количество у документа прихода. Если грохнуть прошлый период, то первой копии версии тоже не будет, соответственно отчет по изменениям ничего не покажет.

Пользователь как минимум не должен иметь возможности "залезть в период 10 летней давности".

Мне вот базу дали посмотреть. Говорят 2 года работали всё было хорошо. А теперь тормозит и тд. Смотрю таблица одного документа добавленного в конфигурацию вешает 5Гб. Открываю... и что я там вижу? А вижу я там фотоотчёты торговых представителей по выкладкам майонеза, кетчупа и тд на витрину. Ну вот и для чего это 2 года хранить в базе не понятно... и зарплата за эти отчёты уже давно выплачена и майонез уже давно продан и съеден. Там может уже и витрины нет никакой.... И вот для них это важная информация. И её нужно хранить....
12. ZLENKO 398 08.01.15 16:40 Сейчас в теме
(11) TODD22, "Пользователь как минимум не должен иметь возможности "залезть в период 10 летней давности""

Речь не идет про 10 лет. В конкретной моей базе история за 1,5 года... и это занимало 90 Гб, а после сжатия 40 Гб. Теперь еще надо почистить от одинаковых записей.
5. ZLENKO 398 31.12.14 11:33 Сейчас в теме
(2) alexinzaz, "Зачем вам версии десятилетней давности. Это же неактуальная информация."

Это все за текущий год накопилось... Работают люди в базе :-)
8. AleksSF 231 31.12.14 13:23 Сейчас в теме
А что стандартными средствами никак. Там есть и удаление устаревших версий и настройка расписания. И настройка срока хранения версий.
9. ZLENKO 398 31.12.14 14:47 Сейчас в теме
(8) AleksSF, "А что стандартными средствами никак."

У меня за при выборке для упаковки периода 1 месяц на сервере temp вырастает до 15 Гб... Сервер начинает тормозить и вылетать с нехваткой памяти..
Поэтому сделал отдельную обработку с выбором периода.
10. ZLENKO 398 31.12.14 14:49 Сейчас в теме
(8) AleksSF, "Там есть и удаление устаревших версий"

За год 2 млн записей... стандартными средствами долго удаляется. Скриптом SQL удаляется мгновенно.
13. SITR-utyos 1438 18.11.16 09:42 Сейчас в теме
Для отправки сообщения требуется регистрация/авторизация