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

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

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

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

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

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

 

13 Comments

  1. ZLENKO

    В одной из баз версии занимали 90 Гб, после сжатия стало 40 Гб. Экономия ощутимая! 🙂

    Reply
  2. alexinzaz

    Ну вот хоть убейте не пойму зачем хранить в базе 90гб версий. Грохать к чертовой бабушке. Зачем вам версии десятилетней давности. Это же неактуальная информация.

    Reply
  3. TrinitronOTV

    (2) alexinzaz, и как её можно грохнуть?

    Reply
  4. Virikus

    (2) alexinzaz, ну как пример, залез кто-то в период 10 летней давности и поменял количество у документа прихода. Если грохнуть прошлый период, то первой копии версии тоже не будет, соответственно отчет по изменениям ничего не покажет.

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

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

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

    Reply
  5. ZLENKO

    (2) alexinzaz, «Зачем вам версии десятилетней давности. Это же неактуальная информация.»

    Это все за текущий год накопилось… Работают люди в базе 🙂

    Reply
  6. ZLENKO

    (4) Virikus, «Другое дело, что блок версионирования лучше переделать на хранение версий в другой базе данных.»

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

    Процедура ЗаписатьВерсиюОбъекта(знач СсылкаНаОбъект,
    знач ЧислоВерсийОбъекта = Неопределено,
    знач ХранилищеДанных) Экспорт
    …
    //МенеджерЗаписиИИО.ВерсияОбъекта = ХранилищеДанных;
    МенеджерЗаписиИИО.ВерсияОбъекта = Новый ХранилищеЗначения(ХранилищеДанных, Новый СжатиеДанных(9));
    //МенеджерЗаписиИИО.Сжато         = Ложь;
    МенеджерЗаписиИИО.Сжато         = Истина;
    …
    

    Показать

    Reply
  7. ZLENKO

    (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
    

    Показать

    Reply
  8. AleksSF

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

    Reply
  9. ZLENKO

    (8) AleksSF, «А что стандартными средствами никак.»

    У меня за при выборке для упаковки периода 1 месяц на сервере temp вырастает до 15 Гб… Сервер начинает тормозить и вылетать с нехваткой памяти..

    Поэтому сделал отдельную обработку с выбором периода.

    Reply
  10. ZLENKO

    (8) AleksSF, «Там есть и удаление устаревших версий»

    За год 2 млн записей… стандартными средствами долго удаляется. Скриптом SQL удаляется мгновенно.

    Reply
  11. TODD22

    (4) Virikus,

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

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

    Мне вот базу дали посмотреть. Говорят 2 года работали всё было хорошо. А теперь тормозит и тд. Смотрю таблица одного документа добавленного в конфигурацию вешает 5Гб. Открываю… и что я там вижу? А вижу я там фотоотчёты торговых представителей по выкладкам майонеза, кетчупа и тд на витрину. Ну вот и для чего это 2 года хранить в базе не понятно… и зарплата за эти отчёты уже давно выплачена и майонез уже давно продан и съеден. Там может уже и витрины нет никакой…. И вот для них это важная информация. И её нужно хранить….

    Reply
  12. ZLENKO

    (11) TODD22, «Пользователь как минимум не должен иметь возможности «залезть в период 10 летней давности»»

    Речь не идет про 10 лет. В конкретной моей базе история за 1,5 года… и это занимало 90 Гб, а после сжатия 40 Гб. Теперь еще надо почистить от одинаковых записей.

    Reply
  13. SITR-utyos

    Вот еще хорошая штука http://infostart.ru/public/191128/

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *