netka!кажется, копить уже нечего. Блокировки исчезли. Больше всего подходит теория Марка: база была создана в начале января, с начала месяца загрузка ее была минимальна, а в пятницу начали восстанавливать последовательность по партиооному учету и проводить документы пачками, нагрузка резко возросла, буферных пулов стало не хватать. После включения автосбора статистики и ручного принудительного запуска сбора статистики в понедельник ситуация стала лучше. Сегодня монитрою размер буферных пулов - уже за полдня часть из них увеличилась в размере (я правильно понимаю, что эту инф-цию показывают снэпшоты?), с прошлой недели до сегодняшнего дня размер памяти для базы (database_memory) стмм увеличил в 6 раз примерно до 3068705. (на сервере 36 Гб ОЗУ, 2 рабочих базы и 5 тестовых)
Просто хочется докопаться до истины, потому что причинам блокировок не особо много информации.

Блокировки и их причины более-менее описаны в руководстве администратора.

Но вы не путайте блокировки с дедлоками. Сама по себе блокировка - это нормально для DB2 (да даже и версионники не обходятся без блокировок совсем), дедлок возникает при "неподходящем" порядке.

Скажем, X1 заблокировал A и хочет заблокировать B, X2 заблокировал B и хочет заблокировать A, их блокировки несовместимы - очень грубая картина такая, хотя, ввиду разнообразия видов блокировок, есть много подробностей.

Если, к примеру, X1 не хотел бы блокировать B в момент, когда тот занят X2, никакого дедлока бы не было. Возможно, вы перестали видеть дедлоки просто потому, что планы поменялись и транзакции стали двигаться шустрее. Интересно, что даже на одном и том же запросе возможны разные блокировки при разных планах доступа.

А, по-хорошему, о предотвращении дедлоков должны заботиться разработчики приложения. Так, если A и B в одной транзакции могут блокироваться только в таком порядке, описанная мной ситуация не возникнет.