Советы по упаковке данных

Есть у меня в базе данных две большие таблицы, на 300М и на 70М записей.
Первая таблица содержит биллинговые записи (деньги), вторая таблица содержит сессии (длительность).
У одного объекта в течении объекта добавляется множество записей (в ряде случаев даже за один день объекту добавляется множество записей).
Я хочу сократить размер БД, "объединив" записи в месячные интервалы (то есть выполнив группировку+сортировку, записать результат в новую запись, а старые записи удалить). Но с такими объемами это нужно делать осторожно.
Скрипт может работать долго, главное чтобы он не нагружал сервер (процессор и память).
Я так понимаю, что вначале мне нужно составить список заданий (клиенты и периоды, которые подлежат упаковки), после чего в цикле осуществлять агрегацию записей. Не посоветуете, как это правильно делается? В таблицах есть индексы по идентификатору клиента и по дате записи.
________________________
Мы смотрим с оптимизмом...
...в оптический прицел.

Alibek B.,

автор
две большие таблицы, на 300М .

- на сидюк влезет. должны быть более весомые предпосылки, чем интуитивное "чет нето".

Тем более

автор
"объединив" записи в месячные интервалы (то есть выполнив группировку+сортировку, записать результат в новую запись, а старые записи удалить)

судя по всему произойдет потеря детализации, в результате которой можно и по шапке.

имхо: не трож - не пахнет

Таблицы постоянно меняются или это типа архив? Сколько в результате будет создано записей?

Если не много, то проще и быстрее будет сделать insert as select за несколько месяцев по всем клиентам, а затем постепенно удалить агрегированные записи. Индексы лучше не использовать, потому как обработать нужно почти все записи.

Посмотри пакет DBMS_PARALLEL_EXECUTE. Он позволяет разделить большую работу на части и сохранять промежуточный результат, даже в случае сбоя в одном из заданий.

На сервере СУБД общий объем дискового пространства 800ГБ, из которых занято уже 550ГБ.
Плюс к этом я ожидаю увеличения скорости роста данных, поскольку сменил расчетный период с месячного на суточный.
Данные я должен хранить 3 года, на более старых данных вполне можно и потерять детализацию.

Perl'ун
Таблицы постоянно меняются или это типа архив?

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

Alibek B.
Есть у меня в базе данных две большие таблицы, на 300М и на 70М записей.

сколько занимают места они?

eev
на сидюк влезет

мы не знаем размер записи.

и тут не совсем ясно, дба ТС или разработчик.

select t.table_name
, t.pct_increase
, t.initial_extent
, t.next_extent
, t.num_rows
, t.avg_row_len
, round(t.num_rows*t.avg_row_len/1024/1024,3) tsize
, t.blocks
, round(t.blocks/256,3) upper_size
from user_tables t
order by UPPER_SIZE desc

TABLE_NAME PCT_INCREASE INITIAL_EXTENT NEXT_EXTENT NUM_ROWS AVG_ROW_LEN TSIZE BLOCKS UPPER_SIZE BM_SERVICE_MONEY 65536 212490290 64 12969 378 1964560 7674 063 RADACCT 65536 35704479 227 7729 451 1140284 4454 234 BM_ACTION_LOG 65536 2365697 182 410 611 63137 246 629 DAILY_BACKUP 65536 10798577 16 164 773 31517 123 113 BM_LOG_DATA 65536 499302 166 79 044 13157 51 395 BM_PAYMENT 65536 303654 174 50 388 7426 29 008 BM_ACCOUNT_FLAG 65536 474435 33 14 931 6292 24 578 BM_COUNTER 65536 704115 45 30 217 4906 19 164 BM_SRV_CNT_LINK 65536 1448284 18 24 861 4780 18 672 BM_SERVICE_ACTUAL_STATUS 65536 437810 28 11 691 2008 7 844 ...

Недоглядел на символ-разделитель.
Просьба модераторам подправить прерыдущее сообщение:

TABLE_NAME PCT_INCREASE INITIAL_EXTENT NEXT_EXTENT NUM_ROWS AVG_ROW_LEN TSIZE BLOCKS UPPER_SIZE BM_SERVICE_MONEY 65536 212490290 64 12969,378 1964560 7674,063 RADACCT 65536 35704479 227 7729,451 1140284 4454,234 BM_ACTION_LOG 65536 2365697 182 410,611 63137 246,629 DAILY_BACKUP 65536 10798577 16 164,773 31517 123,113 BM_LOG_DATA 65536 499302 166 79,044 13157 51,395 BM_PAYMENT 65536 303654 174 50,388 7426 29,008 BM_ACCOUNT_FLAG 65536 474435 33 14,931 6292 24,578 BM_COUNTER 65536 704115 45 30,217 4906 19,164 BM_SRV_CNT_LINK 65536 1448284 18 24,861 4780 18,672 BM_SERVICE_ACTUAL_STATUS 65536 437810 28 11,691 2008 7,844

Alibek B.
800ГБ, из которых занято уже 550ГБ.

при условии, что нужно что-то сотворить с 2х300М - это как-то "ни о чем".
Нужно произвести анализ пространства которые занимают все объекты, использование\неиспользование индексов и т.д.

Alibek B.
from user_tables t order by UPPER_SIZE desc

user_segments