На каждой странице данных может располагаться не более 255 записей.
Таким образом, если (в байтах)
pagesz - размер страницы,
rowlen - общая длина записи в таблице
то страница будет заполнена на
min(pagesz, rowlen*255) байт.
Остальное пространство на странице не будет использоваться.

PCTFREE влияет только на LOAD и REORG.
Все остальные операции его игнорируют.

Alexey KuznetsovЕсть ли возможность выделить часть таблицы в отделный контенер который бы был своего рода "архивом" т.е. раз в 3 месяца в него бы переносились данные из этой таблицы, бекапились и вперед, а из активного контейнера эти данные бы удалялись и при еженочном бекапе этот архивный контейнер бы не участвовал. А селекты бы сами знали что при запросе к этой таблице обращаться сначала к активному разделу, а если облом то к "архивному" т.е. для приложения все так бы и осталось как сейчас.Вы можете использовать union all view.
Примерно так:
У вас есть таблица T(D DATE, ...).
1.
Вы делаете 2 таблицы: T_ACT и T_ARC с такой же структурой и загружаете туда записи из T так, чтоб T_ACT.D>='дата_начала_активности' и T_ARC.D<'дата_начала_активности'.
2.
Вешаете CHECK CONSTRAINT'ы:
на T_ACT.D (D>='дата_начала_активности');
на T_ARC.D (D<'дата_начала_активности');
3.
Убиваете T и создаете view T:
4.
Над этой вью вы можете делать все те же sql операции, как и с изначальной таблицей.
Более того, при update даты таким образом, что она перестает удовлетворять check constraint той таблицы, где строка ранее лежала, эта строка физически переносится в подходящую таблицу.
Посмотрите планы запросов с этой вью на разных (3, 5, может и 7) уровнях оптимизации.
Я не помню точно, но по-моему только, начиная с какого-то, оно начинает по запросам с определенной датой лезть только в нужную физ. таблицу, а не во все сразу.

Вам придется поддерживать ссылочную целостность триггерами.