• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

    За 3 месяца вы пройдете путь от начальных навыков работы с SQL-запросами к базам данных до продвинутых техник. Научитесь находить уязвимости связанные с базами данных, и внедрять произвольный SQL-код в уязвимые приложения.

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

    Запись на курс до 25 апреля. Получить промодоступ ...

Вопросы Про Compact Ftindex

dimat

Well-known member
31.07.2008
508
0
BIT
0
Сервер 8.5.3FP2HF25 on Linux Debian
Имеется база base.nsf с общим размером 11,5 Gb, прибавляет в размере 300мб в день примерно, по мере увеличения размера база начинает работать медленнее.
В ней хранятся промежуточные данные для формирования отчетов, то есть некий кэш, который обновляется раз в сутки следующим образом: агентами старые доки удаляются(отсюда +300мб в виде окурков?), формируются новые.
Отсюда первый вопрос: насколько правилен такой подход?

Как то раз попробовал сделать load compact -B base.nsf, размер бд уменьшился примерно в 5-6 раз.
В следующие разы по этой же команде получаю ошибки:
Error compacting base.nsf: Function cannot be perfomed while database is being compacted
Error compacting base.nsf: PRV bucket is corrupt

Так же периодически (несколько раз в день) в консоли вижу ошибку:
Full Text message: Memory allocation error. errcode = 606
Error full text indexing document NT8EC6353A /local/notesdata/base.ft (rc=3892) Not enough memory for Full Text Indexing or Search
Error full text indexing base.nsf: Not enough memory for Full Text Indexing or Search
Размер фт индекса: 4095Mb

Посоветуйте что можно сделать?
 

dimat

Well-known member
31.07.2008
508
0
BIT
0
Мыш
В ней не только кэш, там есть доки которые не удаляются, но вариант интересный, на случай если весь кэш перенести в отельную бд, где будут тупо доки кэша и вьюшки для их поиска/выбора.
например так: сделать шаблон бд кэша, агенты формирования кэша останутся в старой бд, + добавить агент который будет удалять старую бд кэша, создавать из шаблона новую и запускать агентов формирования кэша.
Надо обдумать.
 

Мыш

Lotus Team
12.02.2008
1 219
29
BIT
66
Судя по ошибке, попытка одновременного запуска двух компактов. Точно в тот момент компакт УЖЕ не работал? Мож ручками запустили из свойств базы, скажем?
Как вариант - при выключенном сервер фиксап + компакт (и лучше с ключом -с).
 

Мыш

Lotus Team
12.02.2008
1 219
29
BIT
66
dimat, эта ошибка теперь постоянно появляется при компакте? Сервер перезагружали? Возможно, какая-то другая задача базу "держит" - попробуйте глянуть каким-нить Process Explorer'ом (ну прогой, которая показывает, какой процесс какой файл открыл).
Я бы прочекал при выключенном сервере. Можно с ключами компакта еще поиграться. Если и после этого будут ошибки, скорее всего, база повредилась...
 

rinsk

Lotus Team
12.11.2009
1 151
125
BIT
3
Если док-ты массово удаляются агентом и вновь создаются - это плохой подход. Плодятся окурки. Используйте ненужные документы повторно.
Так же рекомендую поставить все последние фиксы на 8.5.3 (FP6) и лучше перейти на 9.0.1 с ODS52. Там вроде поправляли что то с PRV bucket is corrupt...
 
Мы в соцсетях:

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