container integrity lost и как с ним бороться ?

rinsk

Lotus Team
12.11.2009
1 156
126
BIT
47
сервер Win x64 10.1FP2 БД ODS:53 включен DAOS. индексы вынесены.
проперти БД тут -

около 2,5 млн документов. БД типа коммутатора (рефлектор, фрагмент и т.п. - понятно что)- хранение перекрестных ссылок на документы

25.01.2019 22:56:02 Informational, rebuild view needed - collection object was deleted (reading e:\icdc\Share\researchfrg.nsf view note Title:'(DocByExternalCodes) DocByExter')
25.01.2019 22:56:02 Informational, rebuilding view - container integrity lost (reading e:\icdc\Share\researchfrg.nsf view note Title:'(DocByExternalCodes) DocByExter')
25.01.2019 22:56:02 Informational, rebuild view needed - collection object was deleted (reading e:\icdc\Share\researchfrg.nsf view note Title:'(DocByExternalCodes) DocByExter')

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

формула 1 единственной сортированной колонки:
x:=ExternalCode:ExternalCode2:ExternalCode3:ExternalCodeSource;
@Unique(@Trim(x))
сво-во вьюшки вот тут -
254 - это от безисходности - сорри :)

есть у кого такое? как часто? как боритесь?
 

savl

Lotus Team
28.10.2011
2 625
314
BIT
544
2,5 млн документов : Они все "живые"?
DBMT используется?
 

rinsk

Lotus Team
12.11.2009
1 156
126
BIT
47
2,5 млн документов : Они все "живые"?
DBMT используется?
Да - они все живые. И да - там не используется режим удаления , вместо этого документ вычищается от всех полей, меняется поле Form и сохраняется для повторного использования при необходимости.
DBMT - запускаю иногда в ручном режиме.
Но это думаю не главное - главное понять, почему возникает container integrity lost. Причем не только на этой БД но и в других проектах и на других платформах - на centos 7 то же такое наблюдал.
Может это только у меня такие условия?
 

savl

Lotus Team
28.10.2011
2 625
314
BIT
544
daos resync? не помогает?
soft deletion включен? да, понимаю что не удаляется, но сама опция?
 

rinsk

Lotus Team
12.11.2009
1 156
126
BIT
47
Не - не помогает... soft deletions = выкл.
проблеме уже много лет, и тут - или я много лет сам бамбук или его нет у других... (((
 

savl

Lotus Team
28.10.2011
2 625
314
BIT
544
В посте был косяк именно с DAOS и там дали совет:
погасить сервер
удалить физически базу DAOSCatalog
запустить сервер
выпонить sync force для daos

Но текущий случай явно не из тех..
Чаще всего отвечают стандартно: fixup/compact/updall
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
473
вместо этого документ вычищается от всех полей, меняется поле Form и сохраняется для повторного использования при необходимости.
x:=ExternalCode:ExternalCode2:ExternalCode3:ExternalCodeSource;
@Unique(@Trim(x))
похоже что при таком "выдергивании" дока из индекса (что-то там в externalcode) он его все еще пытается посчитать, м.б. в коде домины Race Condition получаются на обновления вьюшек
я так понимаю формула для вьюшки этих "пустых" доков?
 

rinsk

Lotus Team
12.11.2009
1 156
126
BIT
47
похоже что при таком "выдергивании" дока из индекса (что-то там в externalcode) он его все еще пытается посчитать, м.б. в коде домины Race Condition получаются на обновления вьюшек
я так понимаю формула для вьюшки этих "пустых" доков?
Ну не знаю, что оно хочет посчитать, это же классический multivalue key.
Тут же проблема в другом - надежности индексов...
Такое по моим наблюдениям бывает и на одном поле...
Это опять таки к сайзингу бд - можно ли что то серьёзное класть в домино ;)
 

savl

Lotus Team
28.10.2011
2 625
314
BIT
544
при учете, что сами IBM, а теперь HCL рекомендуют: не более 300 тыс документов в базе, то ответ приходит сам собой...
 
  • Нравится
Реакции: VladSh

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
473
Тут же проблема в другом - надежности индексов...
да..., но я не уверен что в нетранзакционных системах за целостностью индекса тщательно следят ;) (в смысле - инженеры уделяю внимание)
а индексы вынесены из БД, да и вопщем - дает ли к-л профит (кроме экономии места и нек. возможного ускорения) вынос индексов?
 

rinsk

Lotus Team
12.11.2009
1 156
126
BIT
47
Тут похоже дело в ДНК самих вьюшек...
почему то там допустимы ошибки ))) и когда их кол-во достигает некой величины - срабатывает инстинкт самосохранения Домино )))
Типичный результат fixup - f :
15.10.2019 15:43:48 NSF BT: Verification error in view (DocByExternalCodesCat)|DocByExternalCodesCat in database mh/mh66/events_2018.nsf. See NOTES.BRP for dump.
15.10.2019 15:43:48 BTVerifyNode: ERROR in 344715:0, cardinality is 45 - expected 67
15.10.2019 15:43:48 NSF BT: Verification error in view (DocByExternalCodesCat)|DocByExternalCodesCat in database mh/mh66/events_2018.nsf. See NOTES.BRP for dump.
15.10.2019 15:43:48 BTVerifyNode: ERROR in 344715:0, MaxEntry is TRUE - expected FALSE

Вот оно как думает - откуда он expected ?:) От меня?:))
Сам же делает кривизну, а потом удивляется.... expected он...
 

Mikle_GB

Lotus Team
07.07.2016
70
25
BIT
66
А refresh вида обязательно automatic? auto не катит? ну и @unique вынести бы на форму лучше...
ps Может, проще вынести в sql всю эту шляпу?
pps Был бы один ключ поиска в столбце, можно было бы провернуть фокус с universalID, но 4 как-то многовато...
 

rinsk

Lotus Team
12.11.2009
1 156
126
BIT
47
А refresh вида обязательно automatic? auto не катит? ну и @unique вынести бы на форму лучше...
ps Может, проще вынести в sql всю эту шляпу?
pps Был бы один ключ поиска в столбце, можно было бы провернуть фокус с universalID, но 4 как-то многовато...
auto не катит, плавали ( если не обращатся ко вьюхе хоть полчаса - следующий запрос приводит к обновлению - а там уже накидали всего...
в sql уже много чего вынесено...
не не - от ключа не зависит (
в прошлые выходные, там вообще 1 поле key и все:

16.01.2021 01:38:58 NSF BT: Verification error in view Поля\Параметры по ключу|ParamsByKey in database mh/db.nsf. See NOTES.BRP for dump.
16.01.2021 01:38:58 BTVerifyNode: ERROR in 63:0, MaxKeySize is 28 - expected 14
 

Mikle_GB

Lotus Team
07.07.2016
70
25
BIT
66
Ну тем более, много вынесено - значит и это не проблема вынести:)
А если нужно по одному ключу очень быстро искать документ, то делаем так:
1) получаем от ключа хэш через @password/notesSession.hashPassword, в формате UNIDa
2) ставим этот юнид документу, который хранит связанные данные
3) для поиска по ключу - получаем его хэш и делаем @getDocField/getDocumentByUNID
по идее - это самый быстрый индекс в нсф :) а вот почему лотус двоичное дерево не может разобрать, это к амбассадорам вопрос, я не знаю:(
 

savl

Lotus Team
28.10.2011
2 625
314
BIT
544
если не обращатся ко вьюхе хоть полчаса - следующий запрос приводит к обновлению
так может сессия на самом деле обрывается, что и вызывает "затык"

формулы колонок с формулой отбора в противоречия не входят?
и да, я поддержу предыдущего оратора по поводу вычисляемых полей - лучше в документ перенести, быстрее строить будет, особенно на 2,5 ляма доков.
 

rinsk

Lotus Team
12.11.2009
1 156
126
BIT
47
Ну тем более, много вынесено - значит и это не проблема вынести:)
А если нужно по одному ключу очень быстро искать документ, то делаем так:
1) получаем от ключа хэш через @password/notesSession.hashPassword, в формате UNIDa
2) ставим этот юнид документу, который хранит связанные данные
3) для поиска по ключу - получаем его хэш и делаем @getDocField/getDocumentByUNID
по идее - это самый быстрый индекс в нсф :) а вот почему лотус двоичное дерево не может разобрать, это к амбассадорам вопрос, я не знаю:(
Это то же используется, когда совсем нет надежды на view)

формулы колонок с формулой отбора в противоречия не входят?
и да, я поддержу предыдущего оратора по поводу вычисляемых полей - лучше в документ перенести, быстрее строить будет, особенно на 2,5 ляма доков.
ну это проблему не решит - почему бьется вид)
А $Revisions и/или $UpdatedBy не могут гадить?
Это происходит в БД как с переиспользованием доков так и в обычной БД (

От типа колонок не зависит....
Буду копать дальше - попробую включить сохранение NOTES.BRP на боевых...
 
Мы в соцсетях:

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