Здоровье базы, в которой документы все время создаются и удаляются

A

anna

Коллеги, я помню, что почему-то плохо, когда в базе документы постоянно создаются и удаляются. Я понимаю, что в таком случае лучше, чтобы не было SoftDeletion, что нужно делать все время компакт на такую базу. Напомните все имеющиеся грабли, пожалуйста, еще раз.
Такое ощущение, что со временем такая база становится плохой, архивация в ней не идет (clean), после компакта остаются прежние цифры (60%, например).
 
R

romych2004

У нас в такой базе ломался индекс регулярно. При чем ломался прям серьёзно, приходилось его удалять физически с диска(кнопка "удалить индекс" не помогала)
 
  • Нравится
Реакции: anna

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
471
@anna зачем идет постоянное удаление?
Сколько добавляется документов, в месяц?
 
A

anna

Ну ок, а когда сотни тысяч добавляются и чаще удаляются?
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
471
за какой период - год? - создают архив от БД и раз в год удаляют
я транслирую мысль - удалять (доки, часто) не нужно, а если процесс позволяет - просто менять доки (создание тоже - не быстрый процесс)
 
Последнее редактирование:
  • Нравится
Реакции: savl

rinsk

Lotus Team
12.11.2009
1 156
126
BIT
45
Ну ок, а когда сотни тысяч добавляются и чаще удаляются?
По практике, при 200-300 тыщ. окурков уже могут возникнуть проблемы - особенно на ODS < 52 .
Причем бывает что не срабатывает параметр cutoff date (удаление стабов через хх дней) .
Выход - по возможности не удалять документы, а переводить например в пул повторно используемых.
Или периодически запускать агента по удалению стабов -
Доработка для Linux/64 тут:
https://codeby.net/threads/how-to-count-and-delete-deletion-stubs.30190/page-2
Но тут надо понимать риски, в случае наличия реплик на других серверах.
Начиная с 9.0 есть возможность компактить с опциями -REPLICA -RESTART . Учитывая что после нее FT индекс надо перестроить)
 
A

anna

Пасиба, коллеги. В общем, переделала. Правильно, нафиг такое вообще.
 
A

anna

В базе, переделанной, чтобы документы заново использовались, остаются низкие цифры после компакта - 65%. Запускала и вручную - все равно магическая цифра не меняется. Что сделать?
 

oshmianski

Достойный программист
Lotus Team
25.04.2012
711
59
BIT
8
upload_2016-12-8_9-30-18.png

Время жизни окурков, причем не важно, стоит галочка или нет.
 

oshmianski

Достойный программист
Lotus Team
25.04.2012
711
59
BIT
8
Забыл добавить 90 / 3 = время жизни окурков
 

oshmianski

Достойный программист
Lotus Team
25.04.2012
711
59
BIT
8
не, не, галочку трогать не нужно. циферку только.
мне смущает сам факт привязки времени жизни окурков к этому полю. но, индусы решили по-другому...
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
По практике, при 200-300 тыщ. окурков уже могут возникнуть проблемы - особенно на ODS < 52 .
Причем бывает что не срабатывает параметр cutoff date (удаление стабов через хх дней) .
Выход - по возможности не удалять документы, а переводить например в пул повторно используемых.
было у меня раз подобное, взял и поставил не 90 а 0
база подвисла, подвисла так что потом отвисла но cutoff date больше не работал - вообще, никогда

чтобы избежать проблем с окурками на тех базах в которых часто удаляются доки нужно поставить cutoff date = 0, вот чтобы окурки удалялись сразу - тогда база живучая

естественно подобные базы реплицировать нельзя
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!