Каковы основные принципы выбора оптимального размера блока таб.пространства?

--Eugene--
Дата: 21.03.2011 10:30:34
Пожалуйста, подскажите как вы это делаете, или посоветуйте ресурс.
Спасибо
Вячеслав Любомудров
Дата: 21.03.2011 10:34:08
Как правило, 8кб вполне адекватно во всех случаях
Возможно, для объемных таблиц есть смысл увеличить до 16, особенно, если используется сжатие
Только надо иметь ввиду, что если таблица секционирована, все секции должны иметь одинаковый размер блока
--Eugene--
Дата: 21.03.2011 10:36:59
Вячеслав Любомудров,

а для справочных таблиц, содержащих пару-тройку записей вида (id,name) имеет ли смысл выносить в отдельное т.п. с меньшим размером блока?
если да, то насколько меньшим?
Вячеслав Любомудров
Дата: 21.03.2011 10:38:40
Я юзаю 2кб -- уж очень много таких маленьких таблиц
Какого-либо особенного профита, кроме уменьшения общего занимаемого размера, незаметно
softwarer
Дата: 21.03.2011 10:50:39
--Eugene--
Пожалуйста, подскажите как вы это делаете, или посоветуйте ресурс. Спасибо

Имхо случаев, когда стоит отступить от правила "16 Кб для DWH и 8 Кб для остальных" можно перечислить по большим пальцам одной руки.

--Eugene--
а для справочных таблиц, содержащих пару-тройку записей вида (id,name) имеет ли смысл выносить в отдельное т.п. с меньшим размером блока? если да, то насколько меньшим?

Ну вот посчитайте. Допустим, тысяча таких справочных таблиц. В 16Кб-блоке на каждую бесполезно теряется аж 15Кб пространства. Итого суммарно по базе?

Тем более что размер экстента вовсе не обязан совпадать с размером блока...
--Eugene--
Дата: 21.03.2011 10:53:29
softwarer
Допустим, тысяча таких справочных таблиц. В 16Кб-блоке на каждую бесполезно теряется аж 15Кб пространства. Итого суммарно по базе?
а какже чтение, все такое..?
Вячеслав Любомудров
Дата: 21.03.2011 10:56:52
Ну, еще можно учесть, что будет меньше записей в блоке, вопросы блокировки будут стоять менее остро
Но, как правило, такие вещи лучше решать через PCTFREE, особенно если по логике сначала вставляются [полу]пустые записи, а потом сплошные обновления
-2-
Дата: 21.03.2011 11:01:37
Для мелких справочников предпочитаю использовать одну таблицу. Но в ущерб ссылочной целостности. Оракл пока не реализовал ссылку по константе?

Есть еще один мизинец на левой ноге - лобы хранятся поблочно, если их размер вне строки и в пределах пары блоков - потери очень велики.
softwarer
Дата: 21.03.2011 11:06:48
--Eugene--
а какже чтение, все такое..?

Нужные таблицы на две-три записи, по идее, должны не вылезать из кэша. Да и в любом случае, разница... Сколь мне помнится, оракл требует отдельно настраивать размер буферного кэша для каждого размера блока, поэтому не удивлюсь, если неоптимальность распределения (сейчас активно читаю маленькие таблицы, маленький 2К-кэш пыхтит, а потом буду читать большие, будет простаивать) окажется на порядок больше всех еле ощутимых выгод.

Кроме того, как разработчик, я однажды сказал много тёплых и ласковых слов, когда нужный индекс не создался из-за ограничения размера в 4К-блоке.
wurdu
Дата: 21.03.2011 11:24:16
Большой размер блока может помочь в случае с chained rows. Маленький размер может привести к ORA-01450: maximum key length exceeded. Для нестандартных блоков существенно больше багов (судя по всему, в Оракле не особо тестируют с разными блоками). Вообще, табличные пространства с разными размерами блока изначально были предназначены для transportable tablespaces и использовать нестандартный размер надо в исключительных ситуациях, когда выигрыш очевиден. Если начинаются мысли типа сокращаем логические чтения / увеличиваем конкуренцию, то лучше не надо.