Сабж


Письма все одинаковые, кол-во ~17000

например:
1-00033345545-0343545556 -0
1-00033345545-0343545556 -1
....
1-00033345545-0343545556 -17000



как с этим боротся?

ASA 8.0.2.4251

Вариант номер раз: Слишком частая посылка сообщений. База не успела измениться а уже опять позвали dbremote. В этом случае оно сформирует пустое сообщение означающее что мол "я живая, но измений с предущего запуска не было". Метод лечения - посмотреть процедуру запуска dbremote и запускать процесс посылки сообщений реже. (возможно ключ -sd если dbremote висит как сервис)

А что значит база не успела изменится????
Если не было изменений в базе, то будет только 1 посылка маленькая


Варинат номер два: Установлено ограничение на размер сообщений. Слишком урезано то есть. Ключики -l и -g

Ключи выставлены

Полностью согласен


оно так должно работать и работает.....в большинстве случаев


но бывает,что таких вот маленьких писем валится огромное количество за раз


притом т.к.

1-454654545-34343434-0
...
1-454654545-34343434-10000

то это значит что это 1 сообщение, но разбито на много посылок нор посылки то маленькие ну очень...85 байт как было сказано, а ключики выставлены на намного больший максимальный размер сообщения


создается впечатление, что эт глю Sybase

НЕ для roleks-a. Мы с ним про это говорили.

Немного проясню ситуацию.
У меня вскакивала эта проблема.
Происходит сие чудо в момент, когда консолидированной базе надо разослать большие обьемы одновременно каждому удаленному юзеру и юзеров этих много.
Мне удалось остановить процесс рассылки в момент когда это произошло.
Я перевел юзеров на файловый протокол (стоял СМТП) и установил опцию компрессии в 0. Запустил процесс до конца.
Что в результате получилось:
- некоторым юзерам было послано 5 сообщений по ~3 Мб (компрессия на 0)
- некоторым 60 по ~15 Кб
- некоторым 1300 по ~1 Кб

Просмотрел содержимое файлов для тех кому было послано 1300 сообщений и обнаружил что в каждом сообщении было по одному SQL оператору INSERT or UPDATE. Операторы для всех ремоте-юзеров одинаковые.

Я обращался в поддержку, но конкретно мне ничего не ответили.
Одна из идей которую мне подсказали и которая похожа на правду - нехватка памяти для dbremote т.е. значение ключа -m.
На сколько я понимаю - надо правильно установить комбинацию ключей -l и -m. Какие значения оптимальные или как их рассчитать? - никто ответ на этот вопрос дать пока не смог. Или дело в проектировании публикаций ...

Выход (ИМХО) в следующем:
- рассылку по юзерам разнести по времени.
Но это не спасает, когда база долго не была запущена например более суток.
Запуск агента вначале в режиме "только на отсылку" не помогает потому, что он может не для всех сгенерировать сообщение т.е. изменить значение поля Next_send. Проверено.
Может кто знает как изменить значение поля Next_send вручную перед запуском агента ?


Полностью согласен с PaulJB

цитата...
When all remote databases are receiving unique subsets of the operations being replicated, a separate message for each remote database is built up concurrently. Only one message is built for a group of remote users that are receiving the same operations. When the memory being used exceeds the -m value, messages are sent before reaching their maximum size (as specified by the -l switch).

что и происходит......

Проблема
Когда база долго не была запущена, пришло много сообщений

Решение (ИМХО)

1. Увеличить значение ключа -m
2. Запустить 2 копии SQL Remote:
1. - с ключем -r (только получение)
2. - с ключем -s (только отправка) -sd 15s (опрос отправки каждые 15 секунд)

А какие конфликты?

см. Running multiple Message Agents