mott71

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

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

@puks

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

0

mott71

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

mott71

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

@tmyky

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

0

@puks

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

0

mott71

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

mott71

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

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

0

mott71

Не удаляются

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

@puks

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

0

@tmyky

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

0

mott71

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

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

@puks

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

0

mott71

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

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

20.09.2014 07:46:01 Performing consystency 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 consystency 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 consystency 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 consystency 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%)

mott71

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