Одной из причин медленного времени соединения является деактивированная база данных, которая не открывает свои файлы и не выделяет свои буферы памяти и кучи до тех пор, пока первое приложение не попытается подключиться к ней. Попросите своего администратора базы данных подтвердить, что база данных активна перед выполнением ваших тестов. Команда LIST ACTIVE DATABASES (запускаемая с локального сервера DB2 или через удаленное вложение) должна показать вашу базу данных в ее выводе. Если база данных не активирована, пусть ваш DBA активирует ее явно с ACTIVATE DATABASE yourDBname. Это обеспечит доступность файлов базы данных и структур памяти, даже когда последний пользователь отключится от базы данных.
Используйте GET MONITOR SWITCHES, чтобы убедиться, что все ваши мониторные переключатели включены для вашей базы данных, в противном случае вы упустите некоторые потенциально раскрывающиеся сведения о производительности. Дополнительные затраты на отслеживание данных, связанных с этими переключателями монитора, минимальны, в то время как значение данных производительности является значительным.
Если база данных всегда активна, а вещи все еще кажутся медленными, существуют подробные трассировки DB2, называемые мониторами событий, которые регистрируют все, с чем они сталкиваются, в файл, канал или таблицу DB2. Монитор событий операторов - один из тех, к которому я довольно часто обращаюсь для анализа эффективности операторов SQL и гигиены UOW. Я также предпочитаю использовать дополнительное нажатие для записи записей монитора событий в таблицу, а не в файл, поэтому я могу использовать SQL для поиска данных по всем типам шаблонов. Утилита db2evtbl позволяет довольно просто определить нужный монитор событий и создать таблицы для хранения его выходных данных. Команда SET EVENT MONITOR STATE - это способ запуска и остановки созданного вами монитора событий.