Добрый день!
Ошибка возникает при запуске compact или при репликации.
Lotus Domino Server 8.5.1 FP3
база большая 1600000 документов 19ГБ
Подскажите в чем может быть проблема?

Это уже смотрел
http://www-01.ibm.com/support/docview.wss?uid=swg21229462
http://www-01.ibm.com/support/docview.wss?uid=swg21220384
compact -с иногда отрабатывает, иногда выдает вышеуказанную ошибку

Что из себя представляет ID table? Какими средствами можно ее увидеть, оценить размер или фрагментированность и т.д.?

 

всего 1.6ляма доков а ODS какой?

 

Antish
по второму линку описано про ID table...
рекомендую как минимум зачистить stubs - слегка должно помочь....

As documents are added and deleted over time the ID table can become very fragmented and eventually will overflow.

Сколько памяти на серваке? какая ОС?

 

всего 1.6ляма доков а ODS какой?

ODS version: 48

Добавлено:

Antish
по второму линку описано про ID table...
рекомендую как минимум зачистить stubs - слегка должно помочь....

As documents are added and deleted over time the ID table can become very fragmented and eventually will overflow.

Сколько памяти на серваке? какая ОС?

stubs зачищены (живут 1 день)
24ГБ оперативной памяти ОС Windows 2008 R2

 

ODS version: 48

как бы не соответствует версии сервера... уж такие базы надо приводить в первую очередь в 51....

если не помогает - не пора ли подумать о декомпозиции базы на риалтайм+архив хотя бы?

 

как бы не соответствует версии сервера... уж такие базы надо приводить в первую очередь в 51....

если не помогает - не пора ли подумать о декомпозиции базы на риалтайм+архив хотя бы?

на другом сервере ODS 51, ситуация та же, данные в архив сбрасываются ежемесячно

 

уж такие базы надо приводить в первую очередь в 51

може лучше на старую добрую 43? ))

всего 1.6ляма доков

ууу, какие мы храбрые! )))

Antish
А, если прибить все индексы видов (compact -D -c) и почистить стабы? К стати, то, что они в настройках живут 1 день, не значит, что их нет. Може они застряли? Проверь нотеспиком или подобным софтом. Еще фиксап иногда лечит, иногда калечит... Бэкапы делать не забывай.

 

т.е. есть реплики базы на другом сервере с аналогичной проблемой?
тогда похоже имеет место пресловутое сочетание 100К+ доков, частое обновление доков и достаточно большой размер базы...

несколько лет назад ещё на 6-ке видел похожую проблему на 50К доков и 40Гб базе... но там неоднократный фиксапокомпакт (да - и с прибиением индексов) помог... помню помучались чуть ли не сутки...

 

т.е. есть реплики базы на другом сервере с аналогичной проблемой?
тогда похоже имеет место пресловутое сочетание 100К+ доков, частое обновление доков и достаточно большой размер базы...

несколько лет назад ещё на 6-ке видел похожую проблему на 50К доков и 40Гб базе... но там неоднократный фиксапокомпакт (да - и с прибиением индексов) помог... помню помучались чуть ли не сутки...

Ситуация такая, создаём новую реплику, никаких естественно индексов, никаких стабов (scanEZ), через несколько дней при попытке compact -c
как рекомендует IBM получаем ошибку по ID table.

4 реплики, ошибка на всех появляется почти одновременно, ODS48 -1 шт и ODS51 - 3шт.

Все эти рекомендации не помогают, всё делалось, основной вопрос КАК ПОСМОТРЕТЬ ID TABLE ??? Сторонний софт ? API функции, может у кого есть наработки какие по этому вопросу ?

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

В архиве около 3 000 000 документов, но видимо из-за отсутсвия активной записи/удаления никаких проблем нет.

 

Antish
очень интересная ситуация, если у вас там так часто меняются доки, может проблема не в базе а в Transactional logging?
он у вас случаем на всех сервера не одинаков, раз так всё одновременно вылазит?
попытка соктарить жизнь стабов с 90 до 10 не помогает?

 

Antish
очень интересная ситуация, если у вас там так часто меняются доки, может проблема не в базе а в Transactional logging?
он у вас случаем на всех сервера не одинаков, раз так всё одновременно вылазит?
попытка соктарить жизнь стабов с 90 до 10 не помогает?

А как это влияет на нашу ситуацию не разьяснишь ?
Transactional logging включен только на одном сервере.

По поводу стабов, с некоторго времени стоит время жизни 1 день.

 

КАК ПОСМОТРЕТЬ ID TABLE ??? Сторонний софт ? API функции, может у кого есть наработки какие по этому вопросу ?

По этому поводу, посмотри Lotus C API, но врядли тебе даст что-то описание функций... Я так понимаю, что нотес не может толком построить таблицу идентификаторов из-за проблем работы с памятью...

А даунгрейд до 8.5.1FP2 не пробовал?

 

По этому поводу, посмотри Lotus C API, но врядли тебе даст что-то описание функций... Я так понимаю, что нотес не может толком построить таблицу идентификаторов из-за проблем работы с памятью...

А даунгрейд до 8.5.1FP2 не пробовал?

IBM по этому поводу молчит как рыба. По поводу версии, один из серверов 8.02FP4 с ODS48. Там та же фигня.
Эта внутренняя таблица быстро фрагментируется из-за большого количества создания/удаления документов, и достигая
какого то предела (который не известен) начинает сыпать ошибку.

С оперативкой это точно никак не связано.

 

достигая
какого то предела (который не известен)

судя из текста 100К+ документов....

 

По поводу версии

Использую 851фп2 + 43 одс, ошибки такой не наблюдаю, слава Богу!

 

так всё таки интересно в чем трабла то?

 

IBM по этому поводу молчит как рыба. По поводу версии, один из серверов 8.02FP4 с ODS48. Там та же фигня.
Эта внутренняя таблица быстро фрагментируется из-за большого количества создания/удаления документов, и достигая
какого то предела (который не известен) начинает сыпать ошибку.

С оперативкой это точно никак не связано.

Аналогичная фигня приключилась - за прошедшее время удалось найти решение?

 

поставте время жизни стаба 0 дней, должно помочь