Первоначально, когда мы начали переходить на db2 LUW, мы столкнулись с некоторыми проблемами, когда наши таблицы были слишком большими, чтобы поместиться в табличное пространство размером 4K по умолчанию. В результате «давления» с целью сделать это мы просто выбрали табличное пространство по умолчанию размером 32 КБ и поместили туда ВСЕ наши таблицы.
Какое влияние это окажет? Я разговаривал с одним человеком, который сказал, что можно будет сделать базу данных НАМНОГО больше, чем нужно. Это правда? А что с памятью? Будет ли какая-то польза от перемещения меньших таблиц обратно в табличное пространство размером 4K? Я искал на форумах и что нет, но не могу найти хорошего ответа.
Короче говоря, если у вас относительно низкие требования (небольшая база данных, небольшое количество транзакций), я бы не стал утруждать себя настройкой отдельных табличных пространств для разных размеров страниц. Однако существует проблема, связанная с производительностью и пространством, которая воля обостриться, если ваша база данных велика или количество транзакций увеличивается.
DB2 может сохранять максимальное постоянное количество строк на одной странице (источник):
Таблица с длиной строки 12 байт, помещенная в табличное пространство с размером страницы 32 КБ, использует только около 10% каждой страницы, что рассчитывается как (255 строк * 12 байт) + 91 байт служебных данных) / размер страницы 32 КБ = ~ 10%. Это следует учитывать только в том случае, если таблица большого размера, что означает значительную потерю места. Это также снижает эффективность ввода-вывода и буферизации, поскольку фактическое полезное содержимое каждой страницы невелико.
Вероятно, не будет заметной разницы в производительности, если база данных достаточно мала, чтобы полностью уместиться в ваших буферных пулах. Кроме того, если база данных мала, вы, вероятно, не заметите несколько дополнительных гигабайт потраченного места.
Что вы могли оптимизировать (вероятно, то, что думала в IBM), так это то, что вы можете устанавливать табличные пространства на разных устройствах ввода-вывода, а также оптимизировать буферные пулы для конкретных случаев использования. Использование одного и того же пула буферов для всех ваших таблиц может привести, например, к некоторой вторичной функции (например, некоторой задаче уборщика в приложениях), сбрасывающей наиболее часто необходимые данные из пулов буферов. Помещая, например, такие вещи, как временные таблицы, в разные табличные пространства и буферные пулы, вы можете контролировать, для чего используется ваша ценная память. Однако, как было сказано ранее, эти вещи начинают иметь значение только после определенного момента.
Согласно IBM, при базовой установке нет большой разницы в размере или производительности. Любая выгода будет достигнута за счет наличия нескольких табличных пространств и их индивидуальной оптимизации.