ananas2,

Если есть книга, в которой собраны ошибки и узкие места для Оракл, то она же должна абсолютно также подойти под DB2.
Что касается Best practice, то все они описаны в документации - в разных местах, поскольку и относятся к разным проблемам.

Ко мне регулярно обращаются за анализом, шаблон действий прост:

- смотрим на систему в целом, определяя ее мощность - RAM/CPU/Disk/Network. На этом этапе определяем, что ресурсов DB2 дали и она их честно жрет. Тут, кстати, возможно придется покурить доку по OS/SAN/Network. Типовые ошибки
1.БД с дефолтовым буферным пулом в 250 страниц
2. не выполнены рекомендации по настройкам ядра ОС
3. медленный диск (сдохла батарейка кэша или он не включен, что-то еще создает очередь на диск и т.п.)

- Что нагружает любой sql-сервер? Запросы! Их и начинаем мониторить (курим доку про monitoring), хотя, иногда, достаточно посмотреть на снапшоты (убедимся в начале, что счетчики включены). Может у аппликейшн-серверов не включен пуллинг, и сервер db2 занимается исключительно авторизациями, типа на каждый запрос коннект?

Этот этап и есть основная работа. Смотрим на запросы и видим типовые ситуации:

1. тяжелые запросы. От банальной нехватки индексов и кривого проектирования до багов оптимизатора
2. "ватага зайцев мочит льва". Т.е. выявляем однотипную массовую нагрузку - от банальной нагрузки на компилятор динамическими запросами, которые нужно переделать на статику, ошибок проектирования и/или программирования,
до кривых реализаций всяких мокрософтовских технологий аля ado.
3. глобальная ошибка при проектировании системы, тут уже ошибка на уровне днк - нами не лечится

- "...последнее дело, когда уже нечего пить..." это тюнинг. RTFM! AdmGuide - там все подробно, по каждому параметру и соотношению. Ссылки все даны выше

Andy
*** израильский sql-сервер отвечает запросом на запросом