TORT,

Но ведь 32-bit библиотеки должны работать для функций и на 64-bit сервере.
32-bit and 64-bit support for external routines
Вы пробовали, и они не работают?
Какая ошибка при вызове?

Библиотеки должны лежать в SQLLIB\FUNCTION, если в CREATE FUNCITON указано неквалифицированное имя для library_id.

Это какая-то недокументированная функция, которая, может, и раньше когда-то работала, но, видимо, перестала.
Зачем вы ей пользуетесь?
Её документированный аналог:

Да, считайте, что Community Edition - вместо Express-C.
Срока действия нет. Так же можно использовать в промышленном режиме.

TORT,

Найти админа Db2, который может проанализировать, например, на основе кэша запросов, что выполнилось в базе за XX минут пиковой / текущей активности.
Отсортировать результат по основным характеристикам - общие потребление cpu, время выполнения, получить планы запросов из кэша (именно из кэша, а то, бывает, создают процедуры со статическим SQL на пустых таблицах, а потом заливают данные и удивляются, почему статистику пересобрали, а планы статических запросов в процедурах не поменялись сами и остались как были - построенными на пустых таблицах). Сравнить показатели и планы с ожидаемыми.
Посмотреть, что в данный момент и с какими характеристиками работает.

На Linux / Unix есть идйщий в поставке скрипт db2mon.sh, который выполняет такой "дельта-анализ".
Collecting and reporting performance monitor data with db2mon

То же самое вы можете сделать сами, пару раз вызвав руками через XX минут что-то типа запроса ниже.


Соединив по каждому запосу (member, execuatable_id) результат в начале и в конце (конец left join начало), вы можете определить, что и с какими показателями за этот промежуток времени выполнилось.

В каждой новой версии план того же запроса может поменяться.
Нет никакой общей информации типа "средняя производительность работы с временными таблицами в 11.5 заметно хуже, чем в 9.7".

Получите план из кэша и посмотрите, совпадает ли он с ожидаемым.
EXPLAIN_FROM_SECTION .
Если у вас активное использование временных таблиц, то исторический анализ производится несколько сложнее, чем описанный выше. Эти запросы долго в кэше не живут, и ловить их надо с помощью event monitor for package cache (с COLLECT DETAILED DATA, если потом хотите план запроса получить из таблиц этого монитора). У них каждый раз новый executable_id, и агрегировать надо по идентификаторам запроса (SEMANTIC_ENV_ID, STMTID), чтоб их показатели собрать в кучу.

Что вы собираетесь делать с любым из ответов, если даже вы их и получите от, скажем, разработчиков ядра / оптимизатора?
Они там могли поменять что угодно, например, не создавать эти файлы вообще на диске, если данные таблицы помещаются в буфер.
Но что такая информация вам может дать?

TORT,

Нет, общая концепция работы с временными таблицами не поменялась ни в одной связанных с ними областей.
При переходе на новую версию такое нередко встречается - "хороший" план запроса поменялся на "плохой", причем это может быть не связано с временными таблицами вообще.
Модификации, сделанный с оптимизатором в новой версии, действительно не всегда приводят только к улучшениям.
Пытайтесь оптимизировать как-то ваш запрос.