В этом топике - попытка собрать воедино все прочитанное и понятое путем горького опыта.
Теория. (корифеям можно не читать)
Табличное пространство – структура для хранения таблиц, индексов. Размещаются в группах разделов БД. Одно табличное пространство содержит одно или несколько контейнеров (контейнер - каталог, устройство или файл).
Виды табличного пространства:
SMS табличное пространство – пространство, управляемое системой
DMS табличное пространство – пространство, управляемое базой данных
Каждое табличное пространство связано с пулом буферов. Пул буферов по умолчанию IBMDEFAULTTBP.
Пул буферов - память, содержащая страницы с данными таблиц и индексов (кэш). Чтение данных из памяти выполняется гораздо быстрее, чем чтение с диска, поэтому этот параметр очень важен при настройке производительности.
Память для пула буферов отводится при активации базы данных или при первом соединении программы с базой данных. Освобождается после отсоединения всех программ (db2 force application)
При запуске базы данных менеджеру баз данных должна быть доступна память, необходимая для всех пулов буферов. Если DB2 не может получить требуемую память, менеджер баз данных будет запущен с пулами буферов по умолчанию и выдаст предупреждение, что отрицательно сказывается на производительности БД.

Операция чтения производится блоками, т.е. по одному требованию получается несколько страниц (блок) и помещается в пул буферов. По мере чтения и изменения страниц они накапливаются в пуле буферов. Если пул буферов заполняется до считывания новой страницы, то одну из страниц необходимо записать на диск.

Очистка страниц - перемещение данных из пула буферов обратно на диск.
Средства очистки страниц. Чистильщики - записывают на диск одну из измененных страниц и активизируются если:
Превышен параметр SOFTMAX
Число чистых страниц упало слишком низко
Страница выбрана для удаления из буфера
Значение параметра (chngpgs_thresh, %) превышено

Таким образом, число чистильщиков страниц должно быть достаточным для эффективной и производительной выборки. (параметр БД NUM_IOCLEANERS).

Прим. В ранних версиях DB2 размер пула буфера необходимо было увеличивать вместе с параметром базы данных DBHEAP. В версии DB2 v8.2 память для пула буферов стала независимой от памяти БД (database shared-memory).

Настройка пула буферов.
Можно сказать ключевой параметр, влияющий на производительность DB2.
Мониторинг буферных пулов.
Включить возможность мониторинга буферных пулов. Команды
db2 update dbm cfg using DFT_MON_BUFPOOL ON, или
db2 update monitor switches using bufferpool on
Получить снимок
Db2 get snapshot for all bufferpools
Результат.
Bufferpool name = IBMDEFAULTBP
Snapshot timestamp = 01/22/2008 12:30:00.715058
Buffer pool data logical reads = 9706
Buffer pool data physical reads = 24
Buffer pool temporary data logical reads = 91
Buffer pool temporary data physical reads = 0

Чем больше читается из кэша (logical reads) и чем меньше обращений к диску (physical reads), тем выше производительность. Оптимальное значение >80-90% и вычисляется по формуле:
HitRatio = (sum(logical reads) – sum(physical reads))*100/ sum(logical reads)
По индексам расчет аналогичный.
Очистить счетчик монитора можно командой reset monitor all
Изменение пула
Db2 alter bufferpool IBMDEFAULTBP immediate size 2000
Db2 stop force
Db2start

Агенты
MAXAGENTS – максимальное число агентов, которые в любой момент времени готовы принимать запросы от приложений
NUM_POOLAGENTS – размер пула агентов. По умолчанию половина MAXAGENTS
NUM_INITAGENTS – кол-во агентов инициализируемых при старте менеджера БД
MAX_CONNECTIONS – максимально кол-во разрешенных подключений
MAX_COORDAGENTS – максимальное число координирующих агентов
MAXCAGENTS – коннекты

При работе с большим количеством одновременных подключений следует увеличить значение NUM_POOLAGENTS, чтобы избежать затрат, связанных с частым созданием и уничтожением агентов.

Соответственно при выключенном концентраторе подключений значение имеют параметры
MAXAGENTS = макс. Количество подключений ч-з DataSource + макс.кол-во подключений для сессии (in the session manager)
Узнать кол-во одновременно подключенных пользователей можно
db2 get snapshot for database on [имя БД]
искомые параметры
High water mark for connections = 36
Application connects = 113 – всего подключений
Secondary connects total = 0
Applications connected currently = 34 – текущих подключений
Appls. executing in db manager currently = 0
Agents associated with applications = 34
Maximum agents associated with applications= 36
Maximum coordinating agents = 36

Информация о запущенных агентах db2 get snapshot for dbm
Agents assigned from pool = 1071
Agents created from empty pool = 18
Agents stolen from another application = 0
High water mark for coordinating agents = 17
Max agents overflow = 0
Hash joins after heap threshold exceeded = 48
Особое внимание стоит уделить значению Max agents overflow. Если отлично от нуля – стоит увеличить значение MAXAGENTS.

Предварительная выборка. Может выполняться асинхронно с выполнением запроса. Цель – уменьшить время ответа.
Параметр БД NUM_IOSERVERS.
Мониторинг. Db2 get snapshot for all bufferpools
Buffer pool data physical reads = 1897
Asynchronous pool data page reads = 527
Чистильщики.
Параметр NUM_IOCLEANERS
Рекомендации. Если БД большое количество модифицирующих запросов (INSERT, UPDATE, DELETE), то чем выше этот параметр, тем большее количество агентов будет запущено для записи «грязных» страниц. Высокое значение этого параметра оправданно также в тех случаях, когда используется большой пул буферов.
Этот параметр следует повышать, если Buffer pool data physical reads намного превышает параметр Asynchronous pool data page reads.

Куча сортировки (Sort Heap) – часть памяти DB2, где она размещает данные во время сортировки.
Параметры БД
Sort heap thres for shared sorts (4KB) (SHEAPTHRES_SHR) = 256000
Sort list heap (4KB) (SORTHEAP) = 38400
SQL statement heap (4KB) (STMTHEAP) = 15360
Мониторинг. db2 get snapshot for database on [имя БД]
Total Private Sort heap allocated = 0
Total Shared Sort heap allocated = 0
Shared Sort heap high water mark = 0
Total sorts = 355936
Total sort time (ms) = 19306
Sort overflows = 594
Active sorts = 0
Подсчитать среднее количество времени на сортировку не составляет труда.
Если значение Sort overflows слишком большое – следует увеличить SORTHEAP
Порог кучи сортировки (SHEAPTHRES_SHR). Это значение предохраняет от использования чрезмерно больших объемов памяти для большого числа сортировок. Значение этого параметра должно как минимум вдвое превышать значение SORTHEAP.

Или db2 get health snapshot for database on [имя БД] show detail
Индикатор db.spilled_sorts
Indicator Name = db.spilled_sorts
Value = 21
Unit = %
Evaluation timestamp = 01/18/2008 16:21:45.378667
Alert state = Normal
Formula = (((383 - 0) / ((1798 - 0) + 1)) * 100)
Слишком большой параметр SORTHEAP может отрицательно сказаться на количестве свободной памяти и в целом на производительности. При изменении этих параметров следует помнить, что важно найти компромисс между производительностью сортировки и использованием памяти.

Блокировки (lock). Мертвые блокировки (deadlock)
Параметры БД
Interval for checking deadlock (ms) (DLCHKTIME) = 10000
Percent. of lock lists per application (MAXLOCKS) = 30
Lock timeout (sec) (LOCKTIMEOUT) = 40
Max storage for lock list (4KB) (LOCKLIST) = 64000
DLCHKTIME - Интервал проверки тупиковых ситуаций. Чем больше этот параметр, тем реже проверки, больше время программы ожидают разрешения тупиковых ситуаций.
MAXLOCKS – максимальное количество блокировок. Когда процент списка блокировок достигает MAXLOCKS, менеджер БД выполняет расширение блокировок – блокировки строк преобразуются в блокировки таблицы. Что отрицательно сказывается на производительности. Если установить слишком маленькое значение параметра, то расширение блокировок произойдет когда для других программ все еще будет оставаться достаточно пространства блокировок. Формула maxlocks = 2 * 100 / maxappls.
LOCKTIMEOUT - Срок ожидания блокировки, в течение которого программа будет ждать получения блокировки. Это помогает избегать глобальных тупиковых ситуаций для программ. При значение 0 ожидания блокировок не происходит. Рекомендуется установить от 20 до 30 секунд.
LOCKLIST - Количество памяти, которое отводится для списка блокировок.
Параметры MAXLOCKS и LOCKLIST взаимосвязаны и их следует конфигурировать одновременно.

Мониторинг db2 get snapshot for locks on [BD name]
Или тот же db2 get health snapshot for database on [имя БД] show detail, значение индикаторов db.locklist_util, db.apps_waiting_locks
db2 get snapshot for database on [BD name]
Locks held currently = 0
Lock waits = 722
Time database waited on locks (ms) = 2817463
Lock list memory in use (Bytes) = 32040
Deadlocks detected = 139
Lock escalations = 0
Exclusive lock escalations = 0
Agents currently waiting on locks = 0
Lock Timeouts = 0
Number of indoubt transactions = 0
Эскалация блокировок (LOCK ESCALATION). Причины возникновения данной ситуации
Длительные транзакции. Мертвые блокировки.
Ситуации эскалации блокировок также отражаются в журнале db2diag.log.
Настройка.
Значение Lock list memory in use (Bytes) может служить ориентиром для установки параметров LOCKLIST и MAXLOCKS.
Значение параметра LOCKLIST можно рассчитать, опираясь на данные о максимальном количестве одновременно подключенных приложений (Max Ap Concurent), среднем количестве удерживаемых блокировок (Avg App Held). 4096 – размер блока.
LOCKLIST = Max Ap Concurent * Avg App Held * 72 / 4096

Концентратор подключений. (Connection concentrator)
Для Web приложений характерно множество связанных временных подключений. Концентратор подключений в таком случае является одним из решений для повышения производительности, уменьшая количество памяти, используемой для каждого подключения. В версии DB2 UDB V8 он работает подобно монитору транзакций, позволяет держать 1000 подключений (concurrent connections) на 1000 агентов. Когда концентратор включен количество координирующих агентов (coordinator agents) сокращается, соответственно количество подагентов тоже.
Чтобы включить концентратор достаточно выполнить следующее условие:
MAX_CONNECTIONS > MAX_COORDAGENTS.

Реорганизация и сбор статистики.
Автоматическую реорганизацию и сбор статистики лучше сразу отключить и поместить эти задачи в планировщик. При этом целесообразно сначала собрать статистику, потом сделать реорганизацию.
Конфигурация БД
Automatic database backup (AUTO_DB_BACKUP) = OFF
Automatic runstats (AUTO_RUNSTATS) = OFF
Automatic reorganization (AUTO_REORG) = OFF

JDBC подключение
Пул подключений.
JDBC providers > Default DB2 Universal JDBC Driver Provider (XA) > Data sources > DS > Connection pools

Пул подключений. (connection pool)
Размер пула. Настроить размер пула можно, воспользовавшись Tivoli Perfomance Viewer. Раздел JDBC connection pools. Отслеживаемый параметр – Percent Used. Если его значение слишком маленькое – следует уменьшить количество подключений в пуле.
Оптимальной производительности можно добиться, если количество подключений в пуле меньше, чем Max Connections. В типичных случаях значение 20-30 коннектов в пуле оказывается оптимальным.

Deadlock
Мертвые блокировки в БД возникают, если на один поток приходится более одного подключения (concurrent connection) и пул подключений к БД недостаточно большой для потоков. Предполагается, что каждый поток приложения требует два подключения (concurrent database connections) и количество потоков равно максимальному размеру пула подключений (maximum connection pool size).
Мертвые блокировки возникают, если выполняются условия: все подключения используются и ни одно из подключений не освобождается.
Для предотвращения мертвых блокировок значение пула подключений необходимо незначительно повысить.

Разработчикам. В приложениях избегать создания более одного подключения на один поток.
Подсчитать размер пула подключений можно по формуле:
T * (C - 1) + 1, где
T – максимальное количество потоков
C - количество подключений на один поток

Параметры пула подключений связаны с параметром подключений, определенных в DB2. Если параметр maximum number of connection увеличили, а в БД нет, то в логе stderr.log можно увидеть сообщение об ошибке (SQL exception).

Statement CacheSize
Этот кэш содержит подготовленные (Prepared) SQL запросы.
Если кэш не достаточно большой, то одна из уже подготовленных SQL конструкций выкидывается из кэша и готовиться вновь прибывшая.
Для настройки КЭШа можно использовать тот же Tivoli Perfomance Viewer. Необходимо отслеживать параметр PrepStmt Cache Discard (сколько отброшено SQL конструкций). Соответственно оптимальное значение должно стремиться к нулю.

Прикреплены схемы для иллюстрации сказанного

Получить справку об ошибке
db2 ? SQL0289
получить рекомендации для индикатора
get recommendations for health indicator [имя индикатора] for database (или dbm, tablespace,)
on [имя БД] global

Было бы неплохо еще и с примерами.
И с рассмотрением типичных ситуаций. И с пошаговой инструкцией :) Литературы на русс.языке крайне мало.
Full transction log и борьба с ним
Мертвые блокировки при работе с WebSpher'ой
еще пример восстановления из бэкапа с учетом разных табличных пространств (SMS, DMS)
А еще описание мониторинга с помощью стандартных средств DB2.
Понятно, что есть такая штука как Spotlight QC, однако не у всех она есть
При работе с DB2 поражает большое кол-во параметров взаимосвязанных между собой, например сортировка
Менеджер БД sheapthres порог кучи сортировки, Sort heap thres for shared sorts (SHEAPTHRES_SHR),
Sort list heap (SORTHEAP). Понятно, что чем их больше, тем точнее можно подобрать параметры. Проблема в том, что у нас программы не ТЕСТИРУЮТСЯ, от разработчиков никаких рекомендаций кроме - "мониторьте и тюнингуйте" нет. а на рабочих БД экспериментировать чревато.
Вообще говоря почему бы не сделать wizard'ы по блокам, например конфигурация блока параметров, связанных с блокировками. Берем результаты мониторинга, собираем в кучу все рекомендации, расчитываем зависимые параметры - выдаем уже готовые параметры пользователю.
Наверное это у меня от лени, однако как известно лень - двигатель прогресса.

рекомендации, которые выдает Health Monitor - это конечно хорошо, но на мой взгляд хотелось бы еще проще и эти рекомендации особенно по параметрам сортировки - увеличить кучу сортировки не всегда корректны

Из первоисточника
In prior DB2 UDB versions it was necessary to increase the DBHEAP parameter
when using more space for the buffer pool. With version 8 nearly all buffer pool
memory, including page descriptors, buffer pool descriptors, and the hash tables,
comes out of the database shared-memory set and is sized automatically.
Неужели вы FixPack'и не накатывали?
По поводу приравнивания версий у DB2 достаточно запутано написано на сайте IBM.

Сорри, ошиблась. про концентратор
.. держать 1000 подключений (concurrent connections) на 100 агентов

Ключи мониторинга. В конфигурации менеджера БД
команда db2 get dbm cfg
Default database monitor switches
Buffer pool (DFT_MON_BUFPOOL) = ON
Lock (DFT_MON_LOCK) = OFF
Sort (DFT_MON_SORT) = OFF
Statement (DFT_MON_STMT) = OFF
Table (DFT_MON_TABLE) = OFF
Timestamp (DFT_MON_TIMESTAMP) = ON
Unit of work (DFT_MON_UOW) = OFF
Monitor health of instance and databases (HEALTH_MON) = ON