medoed,

Если хочется разобраться, то это всегда пожалуйста.

Первое, что надо понять, это что такое "отожрано 2 гига" и что такое "встало колом". То, что Вы должны уточнить у своего админа.
Взаимосвязь между этими двумя событиями подсказывает, что выжрано пространство журналов транзакций.


Максимальный размер этого пространства определяется индивидуальным размером файлов журналов (параметр LOGFILSIZ БД), и ограничением на количество журналов LOGPRIMARY (заранее выделенный пул активных журналов) + LOGSECOND (лимит на возможное количество создаваемых дополнительных активных журналов).

В активных журналах СУБД регистрирует _все_ действия по изменениям данных (за некоторыми исключениями, которые не будем сейчас рассматривать), включая изменения данных каталога (описывающих структуру БД).

Информация о _всех_ незакоммиченных транзакциях полностью содержится в активных журналах. Поэтому, если подойти к серваку и просто выключить рубильник (аналог - db2_kill), при следующем старте СУБД проведёт процесс Recovery базы по этим самым журналам, гарантированно сохранив все закомиченные транзакции и откатив незакоммиченные.

Общий размер журналов определяет возможное время рестарта базы после крэша и максимальное время отката транзакций (задавая лимит на собственно размер транзакций).
Для OLTP систем долгие времена по этим операциям критичны, поэтому задрать лимит на размер журналов ("логов", как их называют, что иногда вносит некоторую путаницу в понимании) - во многих случаях не выход ( тем более, что причины, порождающие переполнение журналов, могут быть такими, что увеличение размера не приведёт к желаемому результату ).


Как журналы перестают быть активными.

БД может функционировать в двух режимах:
а) Используя циркулярный механизм логирования - файлы журналов переиспользуются, заменяясь по кругу.
б) Механизм с архивированием журналов - по факту перехода в статус архивных журналы сохраняются тем или иным способом (переносятся в отдельные каталог(и), в систему хранения, на ленточку или ещё куда).

Журнал может быть переиспользован в режиме циркулярных логов или перенесён в архив, _только_ перестав быть активным.
Активным журнал перестаёт быть только тогда, когда все транзакции, данные о которых хранятся в журнале закоммичены или откачены.
Журналы архивируются/отдаются на переиспользование строго в порядке нумерации (по природе механизмов работы с журналами).


Итого, имеем два варианта, при которых журналы могут переполниться:
1. Слишком большая транзакция (кто-то забыл проставить условие в where на updat'e в многомиллионной таблице).
2. Кто-то забыл сделать коммит (на практике встречается чаще), залезши "руками" в базу.

В первом случае всё понятно.
Во втором наполняет журналы отнюдь не виновник, а текущая операционная деательность. Виновник только "держит" журналы, не давая им уйти в архив.

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


Что же со всем этим делать, учитывая, что переполнение журналов останавливает нормальную деятельность СУБД.

1. В случае слишком большой транзакции СУБД, в принципе, справляется с ситуацией сама. Обнаруженный виновник отстреливается, хотя для резрешения ситуации и требуется время на откат транзакции.
Во время "коллапса" все операции на изменения данных будут сопровожлаться сообщениями типа SQL0964C (Transaction Log Full).

2. Вся информация по событиям переполнения журналов будет указана в db2diag.log файле. По нему можно определить время, в течение которого база была недоступна. Там же указан и application handle виновника проблемной ситуации.
Нужно его немедленно пристрелить:
Предварительно сняв снапшот:

В снапшоте будет более подробная информация про негодяя (в большинстве случаев включая и последний выполненный запрос). Там много чего, что может нас интересовать.

3. Для разбора полётов пост-фактум очень хорошо иметь на базе как минимум включённый event monitor на connections (для продуктивных баз я бы сказал, что это must have). Заметной нагрузки это не создаст, но сильно поможет как в этой, так и в множестве других ситуаций.
CONNECTION монитор (как и вовремя снятый application snapshot) позволит выявить id пользователя, аккаунт, откуда и из какого приложения коннектился и т.п. Даже если не удастся полностью локализовать проблему, это даст информацию для старта.


4. Превентивные меры.
а) Можно выставить параметры БД MAX_LOG (максимальное пространство журналов, отдаваемое одной транзакции в процентах от LOGPRIMARY) и NUM_LOG_SPAN (по какому количеству журналов транзакция может быть размазана). Это может помочь в ситуации больших транзакций (но и реально уменьшит доступное транзакции пространство, что не всегда допустимо).

б) Периодически проверять запросом количество используемых журналов и отстреливать самую старую транзакцию (это всегда и есть виновник переполнения в варианте "забытый commit"):

где NNN - количество использованных Secondary Logs, которое можно считать критическим.


PS На самом деле есть ещё один режим работы с журналами - режим неограниченого логирования. Включается установкой LOGSECOND в -1. При этом активные журналы сверх заданного logprimary лимита начинают отправляться в архив и при необходимости извлекаться. Играясь с MAX_LOG и NUM_LOG_SPAN можно при этом добиться разумного времени отката индивидуальных транзакций, но всё равно ряд операций при этом замедлится и общее время recovery БД может неограничено вырасти.