Решено Проблема Архивации Почты.

  • Автор темы Автор темы mall71
  • Дата начала Дата начала
M

mall71

На некоторых машинах архивация производится регулярно. В ручном или автоматическом режиме. Но на сервере базы не очищаются. В результате у пользователей могут быть П/Я размером 200-300МБ, на сервере превышать 1ГБ.

Ответ ищу давно, но ни чего пока не встречал по этому вопросу.
 
Что значит не очищаются? Где у пользователей 200-300 мегов?
 
На локальной машине. После прохождения репликации, копия базы на сервере должна очистится. Но этого не происходит
 
Архивация происходит на машинах пользователей. Архивы соответственно остаются там. После архивации происходит репликация, в результате синхронизации почтовой базы на сервере и клиенте, база на сервере должна, очиститься. База на сервере по составу сообщений должна соответствовать базе клиента. А там остаются не только текущий год, но и прошлый и позапрошлый и т.д.
 
есть такая штука как "окурки" они
Ссылка скрыта от гостей
, по истечении кот. домина забудет об удалениях (если оно не произошло из др. реплики, по к-л причинам)
 
А вообще, если пользователь на локальной реплике удаляет документ, который есть и в локальной базе и на сервере, удаляется ли этот документ в серверной реплике?
 
Такие примеры я наблюдал. Пользователь делает архивацию, затем через 2-3 минуты база на сервере очищается.
 
Про "окурки" я тоже думал, только не могу понять, как в данном случае это происходит.
IBM объяснят два варианта ошибок, при которых восстанавливается старая почта.
1. Если какой либо п/я ни разу не реплицировался в течение периода сохранения "окурков". По умолчанию 90 дней.
У нас репликация настраивается на клиентах 5-10-15 мин. Если предположить, что почта вообще не работала, то такой период вряд ли может превысить 90 дней. Есть у меня пользователи которые могут сидеть одновременно на двух п/я. Например заходит в п/я под Ивановым, еще имеет доступ к почте Петрова. Бывает такое, что почта петрова ни кода не открывалась по его id. Но таких примеров около 1% от всего объема почтовых ящиков.(Но в этом случае, я не знаю, понимает ли сервер, что п\я петрова работает или нет) Есть пользователи которые продолжают хранить в папке "Входящие" важные документы прошлых периодов, но большую часть почты архивируют и содержат п/я в нормальном состояние.
2. Если почту перенесли из архива в папку "Входящие".
Но обычно переносят 1-2-3 документа.
У нас наблюдается большое количество не удаленных документов



Добавлено: Про "окурки" я тоже думал, только не могу понять, как в данном случае это происходит.
IBM объяснят два варианта ошибок, при которых восстанавливается старая почта.
1. Если какой либо п/я ни разу не реплицировался в течение периода сохранения "окурков". По умолчанию 90 дней.
У нас репликация настраивается на клиентах 5-10-15 мин. Если предположить, что почта вообще не работала, то такой период вряд ли может превысить 90 дней. Есть у меня пользователи которые могут сидеть одновременно на двух п/я. Например заходит в п/я под Ивановым, еще имеет доступ к почте Петрова. Бывает такое, что почта петрова ни кода не открывалась по его id. Но таких примеров около 1% от всего объема почтовых ящиков.(Но в этом случае, я не знаю, понимает ли сервер, что п\я петрова работает или нет) Есть пользователи которые продолжают хранить в папке "Входящие" важные документы прошлых периодов, но большую часть почты архивируют и содержат п/я в нормальном состояние.
2. Если почту перенесли из архива в папку "Входящие".
Но обычно переносят 1-2-3 документа.
У нас наблюдается большое количество не удаленных документов
 
У тебя документы восстанавливаются или не удаляются?
 
Не удаляются

Добавлено: Не удаляются
 
Так надо разбираться, почему репликация не работает. Права, логи и тп.
 
несинхрон часов, записи в хистори...
 
Почта продолжает ходить. Нельзя сказать, что репликация совсем не работает.

Добавлено: Почта продолжает ходить. Нельзя сказать, что репликация совсем не работает.
 
Почему? Хождение почты к репликации может не иметь никакого отношения.
 
Сначала написал ответ разность времени у нас возможна 1-3 мин. Но потом покопавшись на сервере, понял что это не принципиально. Пользователь может сделать архивацию сегодня, а запустить репликацию завтра или вообще через неделю. Это одна из ключевых идей работы Lotus. Вы можете работать offLine, а когда есть возможность произвести синхронизацию с сервером. Lotus это не только почта, но и различный документооборот.

Что касается истории:
Архивация произведена 19.09.2014, на сервере файлы не удалились.
20-го ночью запускается nfixup

20.09.2014 07:46:01 Performing consistency check on views in database mail\reg\071102.nsf
20.09.2014 07:46:05 Informational, rebuild view needed - collection object was deleted (reading d:\LINK\mail\reg\071102.nsf view note Title:'($SoftDeletions)|($SoftDeletion')
20.09.2014 07:46:05 Completed consistency check on views in database mail\reg\071102.nsf
21-го ncompact -i -c

21.09.2014 08:58:28 Informational, database design compression is enabled in database mail\reg\071102.nsf.
21.09.2014 08:58:28 Informational, LZ1 is enabled in database mail\reg\071102.nsf.
21.09.2014 08:58:28 Compacting mail\reg\071102.nsf ( 035-07-1102), mail -i -c
21.09.2014 08:59:56 Compacted mail\reg\071102.nsf, increased by 36K bytes (<1%)


Добавлено: Сначала написал ответ разность времени у нас возможна 1-3 мин. Но потом покопавшись на сервере, понял что это не принципиально. Пользователь может сделать архивацию сегодня, а запустить репликацию завтра или вообще через неделю. Это одна из ключевых идей работы Lotus. Вы можете работать offLine, а когда есть возможность произвести синхронизацию с сервером. Lotus это не только почта, но и различный документооборот.

Что касается истории:
Архивация произведена 19.09.2014, на сервере файлы не удалились.
20-го ночью запускается nfixup

20.09.2014 07:46:01 Performing consistency check on views in database mail\reg\071102.nsf
20.09.2014 07:46:05 Informational, rebuild view needed - collection object was deleted (reading d:\LINK\mail\reg\071102.nsf view note Title:'($SoftDeletions)|($SoftDeletion')
20.09.2014 07:46:05 Completed consistency check on views in database mail\reg\071102.nsf
21-го ncompact -i -c

21.09.2014 08:58:28 Informational, database design compression is enabled in database mail\reg\071102.nsf.
21.09.2014 08:58:28 Informational, LZ1 is enabled in database mail\reg\071102.nsf.
21.09.2014 08:58:28 Compacting mail\reg\071102.nsf ( 035-07-1102), mail -i -c
21.09.2014 08:59:56 Compacted mail\reg\071102.nsf, increased by 36K bytes (<1%)
 
Наконец я нашел причину ошибки. Проблема все-таки в настройках репликации. Но фишка в том, что в нашей организации очень много лет считалось, что так настраивать можно. А о побочных эффектах ни кто не задумывался и не разбирался. Нужно зайти в настройки «Опции репликации»/ «Основные»/ «Количество данных для репликации». Поставить галочку «Отправлять документы на сервер» У нас всегда требовали, чтоб галочка была снята. Этим добивались того, чтобы на сервере в почтовых базах пользователей не накапливалась почта в папке «Отправленные». Раньше были большие проблемы с лишним местом на серверах. Но оказывается, это не корректно влияет архивацию. Интересно, IBM исправляло ли эту ошибку. Фикспаки помогут?
 
Для ответа нужно войти/зарегистрироваться
Мы в соцсетях:

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

Верх Низ