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

Чтобы повысить производительность можно ,конечно , самому разбивать такие огромные 
таблицы на куски ,скажем по фактору времени (или другому какому-нить), 
и при обычной оперативной работе иметь дело только с последним временн'ым куском ,
( ну , например за текущий  и предыдущий месяц, а ,может, последние 
 1500  накладных или еще как-нить ).
И при необходимости запроса данных из нескольких кусков использовать свои какие-то 
механизмы переключения между кусками. 
Но! Все это слишком хлопотно при разработке!

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

Повторяю, данная техника должна быть прозрачной для разработчика
и работать тем эффективнее , чем на меньшие куски будет разбита вся 
структура данных. Причем, разбитие , конечно, должно быть динамическим, 
скажем пользователь, заказав в параметрах своего приложения диапазон работы -
последние пару дней , должен работать неимоверно быстрее , чем при установке 
этого диапазона - последние пару месяцев или лет. И только, если в процессе 
работы приложения ему потребуются более старые данные, чем стоят в диапазоне 
работа должна замедляться.

Так вот вопрос - есть ли в Oracle такие механизмы, или придется как и в
настольных СУБД организовывать все это самому со всеми вытекающими проблемами.