Есть много консолидированных баз. Есть много удаленных баз, связанных с этими консолидирванными. Реплики запускаются раз в час и работают через SMTP. Нужно контролировать, все ли реплики работаю хорошо. Вопрос: кто как это делает? Есть ли готовые решения?

В общем, накатал анализатор репликаций. На перле. Типа ОпенСорс. Делает отчеты о репликах в html формате. Анализирует следующие проблемы:
Дата последней applying
Дата последней receive
Дата последней send
Дата последней old recent count
Дата последней missing message
Дата последней sql failed

Анализ проводит по логам утилиты dbremote. Логи берет сам из указанной папочки. Список ремотных юзверов в логе определяет сам. Запускается вручную. Для каждого ремотного пользователя можно определить комментарий, который будет отображаться в отчетах.

Может быть полезен тем админам, у которых есть много репликационных баз и за репликами надо постоянно следить, анализируя логи.

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

Если кому интересно - могу подготовить инструкцию по установке и выложить на своём ФТП. Предоставляется as is без ответственности и гарантий ну и всё такое. Себе поставил, уже работает. Анализирует вроде пока правильно.

Поскольку это типа ОпенСорс, то доступны любые модификации в коде. Ессно без дальнейшего коммерческого использования :о)

Дык. Так оба названных сообщения вписываются в sql failed, кажись

Прошу прощение за дубль

Причем, если "not applying" и "old recent" - это обычные ошибки, то любой "Skipping" определяется как критическая ошибка.

White OwlВыкладывай посмотрим.
Пока я такой контроль делаю простым отчетом в консолидированной базе, собираю список удаленных юзеров, и даты последних репликаций из таблицы SYS.SysRemoteUsers. И цветом выделяю юзеров у которых дата репликации больше чем некоторое количество дней/часов. Большой шеф смотрит этот отчет и устраивает разнос начальникам филиалов за то что они опять забыли оплатить интренет :)

Какая знакомая ситуация! :о)))

Только минус Вашего метода заключается в том, что надо держать коннект к БД с правами dba в момент формирования отчета. А это ограничивает количество админов, которые могут состряпать такой отчет. Я тоже думал над таким решением. Но сделать решил так, как сделал. Коннекты мне вообще держать не надо. И при условии, что логи утилиты dbremote складываются в одном месте по всем базам, мне не надо думать о том, что добавились новые базы или ремотные пользователи - мой скрипт сам их высеивает. А запустить скрипт может любой админ, имеющий учетную запись на сервере. Более того, скрыпт можно запускать по часикам и получать отчеты, скажем, 2 раза в день (обычный виндовый шедулер).

Минусов моего подхода несколько.
1. Надо ставить ActivePerl как доп ПО на сервер БД.
2. Чем больше размер лога, тем дольше идет его анализ. Но пока 5Мб лог обрабатывается меньше 30 сек. И если в логе есть ремотные пользователи, которые уже не работают, то утилита будет давать по ним отчет до тех пор, пока лог не будет обновлен.
3. Если лог обновлен, то утилита не найдет последние applying, receive и skipping для всех юзеров. Но это только первое время, пока не пройдет реплика по всем ремотам.

Кстати, дописал модуль, который рассылает эти отчеты по почте разным юзверам. Список удаленных баз для каждого юзвера можно определить самостоятельно. То есть, если у Вас есть 4 менеджера, каждый из которых следит за своей группой филиалов, то можно сделать так, чтобы каждый из них получал отчет о репликах только своих филиалов. Уже работает. Менеджеры пищат от удовольствия. :о))

Исправил "failed" на "skipping"
Я так проанализировал свои логи, что скипинг - это всегда пропущенная sql инструкция. По крайней мере в моих логах я другой ситуации не обнаружил.

www.gladkov.com.ua

в разделе "разработки" есь Анализатор. качайте, пользуйтесь.
скрипты отработаны и проверены на 7м сервере, winperl с более чем полусотней реплик.

Рыжий Котв названии раздела опечатка - ра р зработки

;)
спасибо. сайт делался ровно 30 минут в принципе только ради выкладывания анализатора