Загадочное дело четырех звездочек

О сколько нам открытий чудных, готовит Lotus Notes...

На днях в своей практике столкнулся с невиданной ранее ошибкой:

Так-так, что у нас тут? О, Ктулху, что это за четыре звездочки в отметке даты последней индексации? Оу, это лотус, детка... поработаешь с ним - и таким штукам больше не удивляешься. Смотрим дальше. Открываем представление "($ALL)", что же у нас там:

Ну дела! Дата модификации - тоже выглядит странно. А ну, что там в свойствах документа?
 

А там, уже ставшие знакомыми нам, звездочки на том месте, где мы ожидали увидеть год. На этом месте у меня возникло неприятное предчувствие... А как же так? Создано 03.02.2015, а модифицировано 03.02.**** ? Это вообще что за год? Интересно! Попробуем выяснить:

Создаем вычисляемое поле с вышеуказанной формулой. Открываем документ:

Whaaaaaaat?!!! Что это еще за Футурама?!! Год тридцать шесть тысяч четыреста восемдесят девятый от Рождества Христова!

Но самый главный вопрос заключается в том, как теперь с этим жить и что важно - как исправлять?

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

Первое, что приходит в голову любому здравомыслящему человеку - часы на сервере сбились. Лезем, проверяем.
Сервер
OS: Debian Linux 6
Domino: Lotus Domino for Linux 7.0.2
Проверка показала, что время установлено правильно и даже настроена синхронизация с NTP, и что совсем неожиданно - даже Time Zone выбрана корректно.

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

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

Сложив все вышеперечисленное, пришел к заключению, что проблема в самой базе. Ну что же... делаю бэкапы, бэкапы на бэкапы и бэкапы на бэкапы на бэкапы.
Запускаю старый-добрый fixup из консоли. Ошибок не обнаружено.

Разумеется, что в очередной раз, внимательно исследовав диалоговое окно свойств базы - не нахожу там опцию "Ставить отметку времени на 36 тысяч лет вперед". И даже близко похожей по смыслу опции тоже нет.

Самая очевидная гипотеза - нарушение структуры файла хранилища. В пользу этой гипотезы говорит еще тот факт, что сервер находится в стойке, которую довольно часто (к примеру, в прошлом году, это было около 30 раз) отрубают от электричества и бесперебойником он не оснащен. Теоретически, у себя в голове я даже представляю, что должно сломаться в файле, чтобы возник такой эффект. Но, к сожалению, на практике магия этого уровня мне еще не доступна. Notes Storage Facility остается для меня в большой мере, Черным Ящиком.

В любом случае, подкрепить эту гипотезу фактами мне еще предстоит. К счастью, на сервере установлен munin. Можно зайти в базу, отыскать среди всех документов период, когда даты обзавелись звездочками и наложить на график отключений электричества в munin-е. Но это исследование прийдется отложить на следующий раз; как-то так совпало, что на момент написания этого поста, сервер снова не доступен.

Переходим ко второй части Мерлезонского балета: как нам это починить?

Первая мысль: сделать локальную реплику - теоретически, ошибка останется на серверной копии базы, а локальная создастся без ошибки. А затем - подложить локальную базу на сервер.
Проверяем. Нда, не получилось. Звездочки тут как тут.

Второй вариант, который я испрововал - накатил на базу шаблон ntf. Накатилось без ошибок, но проблему не исправило.

В итоге, я психанул и решил действовать радикально:

  • Создал на сервере новую пустую базу.
  • Накатил на нее шаблон дизайна.
  • Проверил, что отметки времени без ошибок.
  • Остановил сервер, забрал испорченную базу на локальный компьютер
  • Использовал скрипт для смены Replica ID взятый отсюда: http://searchdomino.techtarget.com/tip/Use-Script-To-Change-The-Replicaid-Of-A-Database
  • Отреплицировал все документы.
  • Еще раз проверил - отметки времени создаются корректно.
В сухом остатке имеем рабочую базу, но с частью документов, с поврежденной датой.

Возникает вопрос: зачем эти шаманские выкрутасы со сменой Replica ID, если можно просто скопировать документы?

Ну, во-первых: при копировании документов, у них меняется Document UNID. Это дополнительная головная боль, т.к многие структуры внутри базы зависят от него.

И во-вторых, у всех пользователей на локальных клиентах перестанет открываться база, т.к все ссылки указывали бы на старую базу, со старой Replica ID. Это лишний гвоздь в крышку гроба админа, учитывая, что пользователи этой базы не имеют почтовой учетной записи и разослать ссылку на новую базу не удастся.

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