RedBook в помощь - http://www.redbooks.ibm.com/abstracts/sg247467.html

Александр ТарасенкоХочется пересобрать всю таблицу под:
Первое (направление) делить все данные на 2 части.
Второе - дата. Первые числа месяца , 10 лет (соот-но 250 примерно).
Вот это не очень понятно. 25 (24?) кластеров на год - каждый месяц на две части делится? [1 - N], (N - 29/30/31]? Как задаётся условие по измерению?
Или 250 - это всего и деление идёт по "дата с точностью до месяца" + год?

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

Александр ТарасенкоНагрузка на таблицу - запросы для получения данных от всей таблицы по датам до различных по дате (пару месяцев, год и т.д.).
Вот можно чуть подробнее? Не очень понятно.

PAGE SIZE выбирать следует исходя из того какими блоками всё это будет читаться (и писаться). Достаточно наберётся co-located строк, вычитывающихся за раз - прекрасно. Для чтения большими блоками - чем больше, тем лучше (недостаточное количество строк в кластере MDC таблицы будет скорее ошибкой физического дизайна самой таблицы).
Важно! Табличное пространство в данном случае должно быть не REGULAR, а LARGE. Иначе в страницу будут класться максимум 255 строк (== ~10Kb в вашем случае).
У вас по грубым прикидкам под мегабайт данных в день, чтение меньше чем по "по направлению за день" не производится. 32K на страницу будет в самый раз.

EXTENT SIZE выбирается исходя из физических характеристик дисковой подсистемы (размер страйпа в raid) и размером блока для эффективного чтения с дисковой подсистемы.
Я бы лично рекомендовал выставлять _минимальный_ по выходу дисковой подсистемы на точку насыщения по потоковому чтению (что будет позволять на наиболее раннем этапе получать выгоду от параллелизации при разбрасывании контейнеров на разные "диски", если таковые имеются/могут появиться).
В остальном EXTENT SIZE будет влиять на maintenance операции (REBALANCING, EXTENT MOVEMENT после запроса на LOWER HIGH WATER MARK).

"Правильный" PREFETCH SIZE напрямую зависит зависит от количества контейнеров (на разных дисковых подсистемах) и тупо в лоб считается простым умножением количества контейнеров (дисков) на extent size, если extent size выбран по приведённому выше принципу (насыщения скорости потокового чтения + кратности размеры страницы).
Если по каким-то причинам мы выбрали другой extent size, то prefetch size выбираем, сначала посчитав "правильный" extent size.

Теоретически, PREFETCH SIZE можно урезать, если мы знаем, что читать за раз больше чем "столько-то" мы никогда не будем (даже на неэффективно составленых планах запросов), но на практике это мало когда можно грантировать.


NUMBLOCKPAGES и BLOCKSIZE следует подкручивать уже пост-фактум на реальной нагрузке, основываясь на monitor element'ах block_ios и pages_from_block_ios.
Но уверяю, это уже "тонкая настройка", влияющая на co-location читаемых данных в памяти (последующую эффективность процессорных кэшей) и уменьшение накладных расходов по CPU на поддержку карты страниц в буферпуле. Т.е. это уже "о-малое" по сравнению с остальным (физическим дизайном табличного пространства и физическим дизайном таблицы).
Векторное чтение (которое есть сейчас, наверное, практически везде) почти полностью выполнит задачи, которые возлагаются на блоковое.
Занимайтесь всем этим в последнюю очередь.
Если интересно, читайте в доке раздел Prefetching data into the buffer pool и по монитор-элементам block_ios, pages_from_block_ios, vectored_ios, pages_from_vectored_ios.

Александр ТарасенкоНу и как определить OVERHEAD и TRANSFERRATE путь.
OVERHEAD - "время доступа" в тысячных долях секунды, TRANSFERRATE - время чтения страницы (тоже в тысячных долях секунды).
Table space impact on query optimization .
Дефолтовые значения дадут вполне вразумительные с точки зрения работы оптимизатора значения, но правильно, конечно, померять (спросить у storage админов, если система внешняя).


Вообще говоря, очень похоже, что таблица - набор исторических данных.
В таком случае может оказаться более правильным упихать всё в range partitioned таблицу, по факту физически отсортированную по времени и партиционированную по направлению + дате (по месяцам).
MDC скорее для возможностей одновременной свёртки по различным направлениям и физически (по сравнению с обычными и range partitioned таблицами) они хранятся по-другому, что влечёт некоторые накладные расходы.
Важно - сделать после создания ALTER таблицы и установить режим APPEND ON.
Как нарезать разделы по дате - зависит от предполагаемых запросов.

Замена даты на "номер месяца" - вполне обычная практика, но плясать надо от предполагаемых запросов.


BTW Производится ли по таблице выборки по primary key, что таковым является, join'ится ли таблица с чем-либо?