Недавно у нас было несколько неприятных случаев, когда интенсивно используемая база данных Lotus Notes превысила лимит в 64 ГБ.
В базах данных было некоторое свободное пространство, которое позволило нам запустить сжатие базы данных, чтобы решить проблему, но отключение базы данных на достаточно долгое время, чтобы уплотнение для получения эксклюзивного использования базы данных было настоящим кошмаром.
Мы попытались:
Тем не менее пользователи будут отображаться как обращающиеся к базе данных и не допускать уплотнения в монопольном режиме.
В итоге мы прибегли к:
Есть ли более простой способ выкинуть всех из базы данных и принудительно выполнить эксклюзивное сжатие базы данных? Мы запускаем Lotus Domino Server 8.5.3.
compact -B "На месте с уменьшением размера файла". Попробуйте, если вы еще этого не сделали.
В моем понимании drop db.nsf не работает. Пытаться Drop All и если это сработает, вы можете написать код, который удаляет только пользователей, обращающихся к этой базе данных.
Почему бы не реализовать кластер (настроенный для аварийного переключения), тогда вы могли бы переключить пользователей на другого. Тогда у вас будет время исправить БД и запустить компакт. Затем вы также можете удалить БД и позволить ей воссоздать ее со 2-го сервера (воссозданная БД будет уже уплотнена).
Кстати. Я бы включил (если еще не включен) сжатие документов и проектов вместе с LZ1, что может помочь немного уменьшить БД (в зависимости от содержимого).
Вы можете попробовать автономную компактную версию с помощью утилиты ncompact из клиента Notes. Она имеет те же параметры, что и команда compact из консоли Domino, но работает непосредственно с nfs, не открывая Notes или не запуская Domino.
Если вы не хотите перемещать этот огромный nfs, вы можете использовать сетевой ресурс и запустить ncompact поверх него. Я настоятельно рекомендую выполнить исправление и преобразовать его в ODS 5.1, если он использует старую версию ODS.
Я также предлагаю проверить nsf и не позволять им достигать этого размера, архивировать документы, перемещая их в новые копии nsf. Старайтесь поддерживать их около нескольких гигабайт, чтобы можно было часто запускать исправление и сжатие, чтобы убедиться в их согласованности.
Перед заменой реплики на первичном сервере на новую из кластера я предлагаю подтвердить, что количество документов такое же или достаточно близкое, и что структурных проблем с репликой на кластерном сервере нет. Я бы проверил это, запустив compact в базе данных в кластере и проанализировав журнал консоли на сервере кластера на предмет ошибок.
У меня такая же проблема с Compact -C -DAOS ON. он не смог сказать, что сжатие было остановлено преждевременно, потому что другой пользователь изменил его во время сжатия. Остановка задачи роутера, smtp и репликатора решает проблему. Я не знаю, за какую задачу сейчас можно ответить, но работает