Что-то я не нашла ответа на этот простой вопрос - а где у нас логи запуска programs (fixup, compact, updall), которые по расписанию на сервере? Хотелось бы посмотреть, все ли успевают за отведенное время, как у них там вообще дела....

 

Смотрите на сервере в log.nsf во вьюхе для miscellaneous events.

 

Смотрите на сервере в log.nsf во вьюхе для miscellaneous events.

ничего не нашла

 

Попробуйте поискать console.log в папку IBM_TECHNICAL_SUPPORT.
То, что нет логов по компакту с фиксапом - результат кастомизации, по всей видимости. Посмотрите значения полей, где в имени присутствует слово log, в notes.ini на сервере.

 

Попробуйте поискать console.log в папку IBM_TECHNICAL_SUPPORT.
То, что нет логов по компакту с фиксапом - результат кастомизации, по всей видимости. Посмотрите значения полей, где в имени присутствует слово log, в notes.ini на сервере.

Сегодня вдруг компактор запустился не по расписанию, а просто днем. При этом 20 минут висел, заблокировал базу, ел немного памяти, и, похоже, ничего не делал. Что это было, ватсон?
[doublepost=1511771893,1511350046][/doublepost]Вопрос решен - это не логи не пишутся, а не запускаются server tasks на сервере по расписанию.

 

Итак, снова с вами пионерская зорька! [далее нецензурно] Как, по какой причине, и с какого хрена снова вообще не запускается компакт из server/programs?!!! и да, в логи ни при каком раскладе ничего не пишется!!!
Что делать? городить агентами?

 

е запускается компакт из server/programs?!!! и да, в логи ни при каком раскладе ничего не пишется!!!

"тема с...к не раскрыта" какой ФП, какой док програмс (его содержимое), воще програмс доки не запускаются?

 

Я не права, кое-что все-таки логируется.Есть предположение, что работающие агенты не дают работать компактору.

21.01.2018 04:15:57 AMgr: Agent ('TODO|04:15' in 'XXX.nsf') error message: Notes error: Operation cannot be performed at the current time - database compaction in progress. ((Hidden)\Members)
21.01.2018 04:28:49 Error compacting XXXX.nsf: Function cannot be performed while database is being compacted
21.01.2018 04:28:51 Database compactor process shutdown

Параметр -i игнорирует только повреждения документов, поэтому, если это агенты мешают, то придется ставить компактор в "технологический час" - когда не работают агенты.
Соответственно, нам нужен параметр выхода из компактора после окончания технологического часа - некрасиво шотдаунить по сбою.
В Domino >8.5 есть такое:
в notes.ini DEBUG_ENABLE_COMPACT_8_5=1

By adding the parameter Debug_Enable_Compact_8_5=1 to the notes.ini the following options will become available:
-W nn Only Compact those databases which were NOT compacted successful in the last nn days
-w Exclude system databases (Log.nsf, Names.nsf)
-X nn Limit the time for the compact of a single database to nn Minits (only works with the "in-place" compact)
-x nn Limit the total time for Compact to nn Minits
-# nn Start multiple (nn) compact tasks simultaneously

Это все вас касается, если вы несчастные обладатели серверов <9 версии, то есть, у вас нет DBMT Если у вас есть DBMT, то расскажите, насколько вы с ним счастливы?
И как счастливые админы, в понедельник, за утренней чашкой кофе, просматривают отчеты о проделанной работе server/programs, видят ли они, сколько пользы принес компакт и какие базы изменились? Чертов DDM я уже не пытаюсь настроить - он пишет, но такую фигню.....

---- Добавлено позже ----

После исправления server/programs нужно перепускать шедулер или еще что-нибудь? или вообще сервер нужно перепускать? Задачи, запланированные на час ночи, не запускаются, зато пытается запуститься непонятно что в четыре ночи и падает, потому что технологическое время закончилось уже. [достало сил нет]

 

Еще о жизни безумного компакта на сервере 8.5.3:
1. Если мы меняем server/programs: время там, или еще что-то, то сразу настройки не применяются. Непонятно на самом деле, что именно нужно сделать и как перепнуть. Если сделать рестарт шедулера Restart Task sched и Show adminp process all, то через какое-то (неопределенное) время есть шанс, что в Show Schedule отобразится новое расписание, но это не точно.
2. Если вы поставили компакт на 01.00, то есть шанс, что он так и запустится, но, по факту, он еще и днем в час запускается - WTF!!!!.
3. Если вы прописали строку параметров с ошибкой, то компакт запустится с ключом -b, то есть место не освободится и space used базы не изменится, ODS в соответствие с notes.ini не придет. Но только ошибку не выдаст, не надейтесь даже.
4. Невозможно в принципе вычислить (исходя из размеров базы, например), сколько времени займет компакт для большой базы и уложится ли компактор в отведенное время, даже если на сервере отключить все что мешает.

#hate

 

@anna да... некоторые особенности бесят
2. с часами - там тоже все... может оказаться запутано c PM и AM (если локаль сервера это допускает), давно не смотрел эти фичи...
3. но все вполне закономерно, если БД занята - её нельзя перевести на др. ODS , про -b - "интелект" где не нужно - это зло, да
4. это сильно зависит от хар-к сервера и самих доков, аппроксимация для долгоиграющих процессов - это "вранье" почти со 100% вероятностью (смотрим на виндятский проводник, при копировани большого объема и кл-ва файлов )

 

@anna да... некоторые особенности бесят
2. с часами - там тоже все... может оказаться запутано c PM и AM (если локаль сервера это допускает), давно не смотрел эти фичи...
3. но все вполне закономерно, если БД занята - её нельзя перевести на др. ODS , про -b - "интелект" где не нужно - это зло, да
4. это сильно зависит от хар-к сервера и самих доков, аппроксимация для долгоиграющих процессов - это "вранье" почти со 100% вероятностью (смотрим на виндятский проводник, при копировани большого объема и кл-ва файлов )

Какой делаем вывод? В тот же агент, который следит за сохранностью процессов типа adminp, router и CA, дофигачиваем умное расписание компактора, независимое от server/programs - чтобы выбирал одну наиболее несчастную базу, обрабатывал ее и, если еще технологическое время не закончилось (и его много), то брал бы следующую, при этом отписывая логи как-нибудь по-умному, чтобы их тоже можно было к анализу приделать потом.

но что за фигня, 21 век на дворе, а мы за такой фигней вручную следить должны... #annoyed

 

Какой делаем вывод? В тот же агент, который следит за сохранностью процессов типа adminp, router и CA, дофигачиваем умное расписание компактора, независимое от server/programs - чтобы выбирал одну наиболее несчастную базу, обрабатывал ее и, если еще технологическое время не закончилось (и его много), то брал бы следующую, при этом отписывая логи как-нибудь по-умному, чтобы их тоже можно было к анализу приделать потом.

но что за фигня, 21 век на дворе, а мы за такой фигней вручную следить должны... #annoyed

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