Темный падаванМой опыт мониторинга оракловых баз через всякие нагиосы и забиксы говорит - плохая это затея. Дело в том, что любая система мониторинга подобного рода использует sql-plugin, который
1) открывает соединение
2) что-то выполняет
3) закрывает соединение.

Начать с того, что соединение в оракле достаточно дорогой ресурс. Когда вы захотите мониторить 200 параметров в вашей БД, то даже если каждый пробник будет отрабатывать раз в минуту (не в секунду!) - вы гарантированно просядете по производительности. А когда там начнутся реальные проблемы - ваш мониторинг просто добьет ее. Даже 20 пробников могут доставить вам неприятности. Т.е. в данном случае наблюдатель влияет на наблюдаемую систему, и влияет не лучшим образом.
Кроме этого, я пребываю в твердой уверенности, что каждый инструмент нужен для своей задачи. Nagios, Zabbix и другие умеют собирать системные метрики по SNMP (нагрузка на сеть, процессор, ввод/вывод и проч.), причем это никак не повлияет на наблюдаемую систему.
Для мониторинга параметров БД используйте Enterprise Manager. Если вы ярый фанат sqlplus и противник ЕМ - напишите свой пакет с пробниками на plsql, разложите по всем БД и запускайте его через dbms_scheduler. C помощью utl_smtp отсылайте себе оповещения на почту или даже в sms-шлюз.
Системы мониторинга обладают расширенными возможностями, в частности, они умеют довольно успешно предотвращать генерацию спама. Правда, здесь много зависит от прямоты рук. Через любую практически систему мониторинга вы можете гибко настраивать время оповещения, опрашивания системы, число попыток опрашивания системы (БД) и т.д. Всего этого вряд ли имеет смысл добиваться через PL/SQL пакет, живущий как "вещь в себе". Другое дело, что если запрос метрики тяжелый, то имеет смысл действительно выполнять его через PL/SQL, а результат забирать плагином из некоторой таблицы, это хорошая идея!

Что касается ситуации, когда запрос из плагина не может быстро выполниться, то имеет смысл вторую попытку делать не сразу, а через 10-15-20 ... минут или еще позже, т.е. задать большой интервал между попытками в случае неудачи.

Что касается мониторинга 200 параметров - это специфичный случай, встречается редко, но и здесь очень многое зависит от прямоты рук и мало что зависит то конкретного решения по мониторингу (системы). Т.е. грубо говоря не надо человеческий фактор спихивать на систему мониторинга.