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

[mall71]

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

Ответ ищу давно, но ни чего пока не встречал по этому вопросу.

 

[puks]

Что значит не очищаются? Где у пользователей 200-300 мегов?

 

[mall71]

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

 

[mall71]

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

 

[lmike]

есть такая штука как "окурки" они

Ссылка скрыта от гостей

, по истечении кот. домина забудет об удалениях (если оно не произошло из др. реплики, по к-л причинам)

 

[puks]

А вообще, если пользователь на локальной реплике удаляет документ, который есть и в локальной базе и на сервере, удаляется ли этот документ в серверной реплике?

 

[mall71]

Такие примеры я наблюдал. Пользователь делает архивацию, затем через 2-3 минуты база на сервере очищается.

 

[mall71]

Про "окурки" я тоже думал, только не могу понять, как в данном случае это происходит.
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 документа.
У нас наблюдается большое количество не удаленных документов

 

[puks]

У тебя документы восстанавливаются или не удаляются?

 

[mall71]

Не удаляются

Добавлено: Не удаляются

 

[puks]

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

 

[lmike]

несинхрон часов, записи в хистори...

 

[mall71]

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

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

 

[puks]

Почему? Хождение почты к репликации может не иметь никакого отношения.

 

[mall71]

Сначала написал ответ разность времени у нас возможна 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%)

 

[mall71]

Наконец я нашел причину ошибки. Проблема все-таки в настройках репликации. Но фишка в том, что в нашей организации очень много лет считалось, что так настраивать можно. А о побочных эффектах ни кто не задумывался и не разбирался. Нужно зайти в настройки «Опции репликации»/ «Основные»/ «Количество данных для репликации». Поставить галочку «Отправлять документы на сервер» У нас всегда требовали, чтоб галочка была снята. Этим добивались того, чтобы на сервере в почтовых базах пользователей не накапливалась почта в папке «Отправленные». Раньше были большие проблемы с лишним местом на серверах. Но оказывается, это не корректно влияет архивацию. Интересно, IBM исправляло ли эту ошибку. Фикспаки помогут?