Mark Barinsteinпро память: поставьте значения в sysctl.conf, какие я написал, уберите дублирующие строки оттуда, проверьте при первом соединении с базой, будет ли ошибка появляться.
Спасибо. Сейчас с приложением работают. Вечером попробуем.

Mark Barinsteinпо db2acd: health monitor как-то странно воспринимает имя хоста.
дайте вывод:

hostname
db2set DB2SYSTEM
db2 get admin cfg | grep DB2SYSTEM

ping `hostname`
действительно выдаёт ip адрес сервера?
hostname: sl00700030002
db2set DB2SYSTEM: localhost
db2 get admin cfg | grep DB2SYSTEM: LOCALHOST

ping `sl00700030002`: unknown host sl00700030002

Ivan Ivanich
получается, что ему не нравится имя localhost. ну и идёт он лесом в таком случае. я лично скормил ему:
db2set DB2_FMP_COMM_HEAPSZ=0 вроде успокоился.Да. Мы тоже так решали вопрос (по вашей же подсказке). Но хотелось бы разобраться, в чем проблема. Получается, что через localhost из системы вытаскивается реальное имя хоста, а дальше уже по реальному имени не получается вытащить IP. Я понимаю так.

Ivan Ivanichа у меня и на hostname выдало localhostВо! А у нас hostname выдает указанное выше имя. А ping к этому имени не проходит. Хотя ping localhost проходит и выдает стандартный IP - 127.0.0.1. Надо подойти к нашим админам и разобраться. Хотя, мне кажется, в вашей системе в hostname просто явно прописан localhost. Но это не решит проблему. Думаю, если вы пропингуете реальное имя хоста, то он также не пройдет. Попробуйте.

Mark Barinsteinping `hostname`
надо было выдавать как есть, с кавычками, которые у вас в левом верхнем углу клавиатуры.
Если вы уж обозвали так свой сервер, то хоть поставьте его алиасом к localhost в /etc/servces.
Скормив ему db2set DB2_FMP_COMM_HEAPSZ=0, вы должны отдавать себе отчёт о последствиях, описанных в ссылке.Понятно.
ping `hostname`: ping: unknown host sl00700030002

Ну вот, сегодня взглянул в протокол db2diag - ошибок нехватки памяти нет, ошибок db2acd тоже нет. Изредка появлялись другие ошибки, но пока не буду зацикливать на них внимание - понаблюдаю.

Итак, что было сделано:
1. Для исправления ошибки, связанной с тем, что health monitor (db2acd) не воспринимал имя хоста, были внесены изменения в файл /etc/hosts.
2. Для исправления ошибки переполнения памяти были внесены изменения в файл /etc/sysctl.conf (Спасибо Mark Barinstein!).

А теперь возвращаюсь к теме ветки. Проблема была исправлена сразу созданием созданием всех ХП, всех триггеров и всех вьюшек по новой. На тестовом сервере была развернута "хорошая" база, на которой была выполнена команда db2look -d STRAH -u db2inst -z db2inst -e -dp -td @ -o script.sql . В результате был получен скелет базы. Убрал из script.sql все лишнее - оставил только скрипты создания вьюшек, процедур и триггеров. Запустил отредактированный скрипт на рабочем сервере. Все заработало.

Теперь хочу какой-то вывод сделать. Обращаюсь к участникам обсуждения. Значит, надо полагать, что таинственное исчезновение части ХП, всех триггеров и производных таблиц могло произойти только при участии извне? То есть, либо прога что-то не так в тот вечер сделала, либо некий админ запустил скрипты удаления объектов? Сама СУБД не могла натворить делов вследствие нехватки ресурсов? Какие предположения?

Ivan IvanichУбивает приложение. 100% В базе даже процедуры есть по удалению триггеров и хранимок.
Ужас. ) А так же в /script/cfg обратите внимание на содержимое stat.sh там есть
drop-logic и create-logic вот тут засада вся имхо и сидит.Точно! Наверно, в этом все и дело:
При отработке rebind(), возможно, произошел какой-то сбой и он не выполнился полностью.

Ivan Ivanichвсе триггеры и остальная логика лежит в файле create_logic.sql пользуйтесь им.Спасибо.

haykakan, это Вы к чему?