Изучая документацию, нашел очень много интересных и полезных вещей.
Например, чтобы пользоваться XML, теперь не обязательно создавать БД в кодировке UTF-8.
Появился тип данных DECFLOAT - аналог Oracle NUMBER.
Наконец то заработали функции форматированного преобразования даты в строку и назад.
Появились функции с множеством параметров, как пример Oracle decode().
Но мне совсем не понятно, на кой ляд надо было тащить старый синтаксис констркций INER JOIN из Oracle? Речь веду о конструкциях типа (+)= и =(+). Насколько мне известно, начиная с девятой версии Oracle появились нормальные конструкции INER JION.

GVF112GVFЕще могу добавить, что будет поддерживаться - threaded engine architecture (remove Process-Model Limitations )
- Механизм защиты (Authorites/Privileges) на основе ролей - CREATE ROLE (что-то на подобие Informix).
- и т.д.
https://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp

С уважением,
Вадим.
Это то я читал...
Не понятен сам механизм. Кто будет хранить эти самые роли?
Например, самих пользователей и группы пользователей хранит операционная система (или контроллер домена, или LDAP). Мы всего лишь добавляем названия этих сущностей в нашу БД.

Центр управления не имеет окон упрвления данной фичей.

nkulikovСамое прикольное что теперь компрессия может включаться автоматически

А ничего "прикольного" в этом нет. Мы не получаем выигрыша.
1) Старые данные в БД так и останутся не сжатыми.
2) Если первая часть данных - это 0, вторая часть - 1, а оставшиеся - NULL (аналог true/false).
3) Если поле в строке было сжато и мы хотим занести туда другое значение, может сложится такая ситуация, что для хранения измененной строки данных надо будет зарезервировать место на другой странице.

Сначала надо просчитать, будет ли от сжатия данных реальный выигрыш или нет.

Было бы гораздо интересней, если бы в DB2 предложило аналог Oracle VARCHAR2. Когда данные могут храниться на этой же странице, что и все остальные поля записи, но при этом не сильно влиять на ограничение по размеру страницы.