AmKadВ доке заявлено, что compress for oltp (он же for all operations) в отличие, например, от basic, работает для всех DML операций. В частности, для conventional insert он работает.
Всё верно. Я подразумевал basic.
Если в твоем тесте
1) поменять тип на basic
2) увеличить число строк до 1e6
3) добавить --+ append
то результаты будут такими



Время примерно одинаковое. Сжатие для этих специфических данных в 10 раз.
При conventional никакого эффекта не будет ни по времени ни по сжатию.

Если вернуться к compress for oltp, то целесообразность подобного компромисса весьма сомнительна
1. Компрессия как правило применяется к архивным данным, а не активным
2. Прирост нагрузки на CPU таким может быть ощутимым
3. При удалениях и последующих вставках ожидаемого сжатия может не быть.
Имеет множество случаев когда работает "весьма странно". В свое время была у меня подборочка, когда анализировали разные типы.
Можно нагуглить много интересного начиная от блога Льюиса и заканчивая этим форумом move compress for oltp .

wolfiodbms_photoshop,

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


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

Кстати, если, допустим, таблица весит 1тб, индекс ну скажем 200гб, то удалив 500гб из таблицы индекс уменьшится сам? или его нужно пересоздавать?Я эникейщик, а не админ, не стоит извинений.
Стоит только больше думать и читать перед тем как писать.

Все твои суждения про целесообразность (или ее отсутствие) выглядят весьма нелепо из-за крайне низкого уровня знаний и соотвественно бестолковых выводов.
Для того, чтоб минимизировать время простоя ты можешь рассмотреть dbms_redefinition, edition based redefinition или просто грамотное планирование действий в окне простоя системы.
Касаемо скорости записи, как уже было сказано, при испольвании basic и секционирования ты добьешься и сжатия архивных данных (не это ли заголовок твоей темы) и неизменную скорость работы с активными данными.
И самое главное, чтоб подумать и предложить что-то дельное не надо быть специалистом с 25 лет опыта Оракла, достаточно почитать доку, блоги, презентации + много экспериментов.
Ты же просто предлагаешь какие-то инициативы имея крайне поверхностное понимание. И одно дело, если б ты просто определил цель, но ты же строишь нелепые концепции и пытаешься указывать другим.

Kumotoriwolfio... сворачивание на ленту части таблицы возможно?

А вы забумывались про:
Какова процедура доступа к данным, которые вы сбрасываете на ленту?
Сможете восстановить хотя бы 5-ти летние данные? (старые ленты не всегда читаются)
А если у вас не будет совместимого устройства для чтения старых лент? (личный опыт)
А если у вас не будет БД Oracle? (например оптимизация и переход на P...sql и т.п.)
А если у вас не будет своих спецов, а только аутсорс и на удаленке без физического доступа?
и так далее.

Если для вас затраты на хранилище в бОльшем приоритете, чем данные, тогда такие "данные" можно удалять.
А если данные важнее, тогда и компрессия не страшна.Хорошая попытка блеснуть умом, только
Это три разные вещи.

Часто ты при разработке политики архивирования думаешь, что будет если в будущем не будет Оракл и своих спецов?
Я надеюсь возможный ядерный взрыв тоже учитываешь?

Vintdbms_photoshop, немного offtop
вчера вот только в райфе слушал недо_scna, он рассказывал про hadoop и сопутствующие технологии типа oracle big data lite, external tables над hdfs. вот думаю после переезда на 12 попробовать как раз вариант поиграться с вариантами, пока придумал такие:
партицирование и compress данных старше 1 года на некоторых фактических таблицах.
view+ insted of trigger над таблицей с данными за последний год+таблица с историческими данными без индексов
ну и на крайний случай
view+ insted of trigger над таблицей с данными за последний год+external tables над hdfs
скорее всего конечно будет партицирование со сжатием. все таки намного проще реализуемо, но и другие варианты тоже продумываю, еще можешь подкинуть что-то на подумать? данные важны только за текущий год. скорость предыдуших годов не важна. горячие данные только текущий и предыдущий месяц.
Не очень понял зачем insted of trigger. Для хранилищ должны быть очень серьезные аргументы в пользу такого решения.

Data Offload счас предлагают все кто не лень от Oracle и MSSQL и заканчивая специфическими приблудами типа Gluent Smart Connector от Подера.

Я вижу смысл оффлоадить данные только если можно также оффлоадить не только примитивные фильтры и projection, но и такие операции как групировка и при этом данные нужны в более агрегированном виде чем они хранятся (ну или фильтры хорошо фильтруют данные).
Иначе, по факту, only scanning + selection + projection will be offloaded, после чего здоровенная порция данных будет перекачана из hadoop кластера в Oracle для последующих соединений и прочего.

Ясное дело, о выполнении оракловой специфики типа connect by на стороне hadoop и речи быть не может.
По крайней мере на данном этапе развития технологий.
Хотя работу аналитических функций в ближайшие годы, вероятно, может будет вынести.
Они уже реализованы и в Oracle и в той же Impala, но проблема распределить работу.

Для старта - я рекомендовал бы ознакомиться с презентацией Подера Connecting Hadoop and Oracle , потом углябляться в интересующие моменты.

wolfioмне показалось, что лучше спросить опытных людей, чем читать докуДа, тебе показалось.