размер табличной области db2 и влияние производительности

Короче говоря, если бы у Вас есть относительные низкие требования (небольшая база данных, объем транзакций низко), я не потрудился бы настраивать отличные табличные пространства для различных размеров страницы. Однако существует требование к производительности и связанная с необходимой площадью проблема, которая возрастет, если Ваша база данных будет большой или Ваше количество повышений транзакций.

DB2 может сохранить в максимальной постоянной сумме строк на одной странице (источник):

Таблица с длиной строки 12 байтов, помещенных в табличное пространство с 32K размером страницы, использует только приблизительно 10% каждой страницы, которая вычисляется как (255 строк * 12 байтов) + 91 байт издержек) / 32k размер страницы = ~10%. Это - только соображение, если таблица является большой, что означает, что потраченное впустую пространство является значительным. Это также делает ввод-вывод и буферизацию менее эффективного, потому что фактическое полезное содержание каждой страницы является маленьким.

Вероятно, не будет заметного различия с точки зрения производительности, если база данных будет достаточно маленькой для установки полностью bufferpools. Также, если база данных будет маленькой, то Вы, вероятно, не заметите несколько дополнительных гигабайтов потраченного пространства.

То, что Вы могли оптимизировать (вероятно, что IBM думала), - то, что можно установить табличные области на различных устройствах IO и также оптимизировать bufferpools для точных вариантов использования. Используя тот же bufferpool для всех Ваших таблиц может привести, например, в некоторую вторичную функцию (например, некоторая задача швейцара в приложениях) сбрасывание обычно необходимых данных часто из bufferpools. Помещение, например, вещей как временные таблицы в различные табличные области и bufferpools, можно управлять тем, для чего используется ценная память. Однако, как сказано ранее, эти вещи начинают иметь значение только после определенного момента.