Ошибка: Unable To Extend An Id Table - Insufficient Memory

  • Автор темы Antish
  • Дата начала
A

Antish

Гость
#1
Добрый день!
Ошибка возникает при запуске 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? Какими средствами можно ее увидеть, оценить размер или фрагментированность и т.д.?
 
K

Klido

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

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

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

Antish

Гость
#4
всего 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
 
A

Antish

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

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

Akupaka

А че я?.. О.о
04.10.2007
3 360
2
#7
уж такие базы надо приводить в первую очередь в 51
може лучше на старую добрую 43? ))

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

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

Klido

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

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

Antish

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

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

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

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

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

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

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

ToxaRat

Чёрный маг
Lotus team
06.11.2007
3 226
25
#10
Antish
очень интересная ситуация, если у вас там так часто меняются доки, может проблема не в базе а в Transactional logging?
он у вас случаем на всех сервера не одинаков, раз так всё одновременно вылазит?
попытка соктарить жизнь стабов с 90 до 10 не помогает?
 
A

Antish

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

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

Akupaka

А че я?.. О.о
04.10.2007
3 360
2
#12
КАК ПОСМОТРЕТЬ ID TABLE ??? Сторонний софт ? API функции, может у кого есть наработки какие по этому вопросу ?
По этому поводу, посмотри Lotus C API, но врядли тебе даст что-то описание функций... Я так понимаю, что нотес не может толком построить таблицу идентификаторов из-за проблем работы с памятью...

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

Antish

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

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

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

rinsk

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

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

ToxaRat

Чёрный маг
Lotus team
06.11.2007
3 226
25
#18
поставте время жизни стаба 0 дней, должно помочь