Итак, дано: одна база в экземпляре размером 7,3 Гб, DB2 8.2 (8.1+fixpak14, разрешено 2 процессора, 8Гб ОЗУ).
Есть проблема с производительностью, которая выражается для пользователя в медленном открытии окон если они вообще открываются, а на БД в возникновении deadlock'ов на причём с приличных их количеством в течении одного часа.
Приложение построено скорее как DW (Data Warehouse) чем OLTP, т.е. как всё хорошее приложение задумывалось как быстрое OLTP, но получилось DW
Теперь вопросы, во-первых, есть ли разница в настройке dbm и db для включения intra_parallel на 8.2 и 9X DB2 (т.е. для 9Х знаю точно нужно отключить автообслуживание БД те. auto_main off auto_reorg off auto_runstat и тп, параметр среды FEDERATED=NO, далее intra_parallel=YES, dft_degree=Any). Второй, вопрос есть ли какая то разница как работает intra_parallel в 64-битной DB2 и 32-битной.

Mark Barinstein, спасибо это обнадёживает, хотя то народ говорит что intra_parallel может увеличить время обработки запросов, так же как изменение DFT_QUERYOPT с дефолтного 5 на наивысшее 9.
И еще есть "вилка" по автоматическому обслуживанию база постоянно говорит о том что ей хотелось бы получить и runstat и reorg и bakcup, то есть в логe db2diag.log постоянно сыпятся сообщения Level:Event с текстом automatic reorg evalution, монитор постоянно показывает две три таблицы в состоянии требующем то сбора статистики, то реорганизации, причём порой сразу же после прохода таблиц runstat'ом c update статистики и последующего reorg'а.
Сам db2diag.log c 16/01/2009 догнался уже до 95 метров читать его малоприятное занятие, рука тянется поотключать мониторы, но приложение работающее с базой слишком нестабильно. Можно его конечно пересоздать, но у меня был день(сутки) когда в лог нападало почти 800000 строк, т.е. как времменная мера может помочь не надолго :(
Есть какая нибудь утилита более или менее удобоваримая что бы читать db2diag.log от db2 v.8.1 с 17 fixpak'ом (ОС Linux RH)

Sorry, фикспак всё же 14, хотя я их 17 пользую но на другой задаче