Коллеги, привет.
большая база. Есть набор колонок (несколько тысяч), которые надо почистить. Набор - может меняться со временем.
update .. set .. = null - крайне медленно. Может работать неделями, даже через dbms_parallel_execute.
Быстрее всего: удалить (методом set unused column), и сделать точно такую же колонку, как было.
Как собрать sql-команду, которая делает точно такую-же колонку?
Пока вижу 2 варианта:
1) самому склеить из: типа колонки, длины, nullable и default. Это наверняка покроет все наши колонки, но в оракловой спецификации есть ещё незнакомые мне слова, которые могут быть применены для создания колонки: SORT, ENCRYPT, итд. Скорее всего таких колонок в нашей базе нет - но хрен знает, что я встречу завтра.
2) позвать dbms_metadata.get_ddl, и выкусить оттуда место, где описывается колонка.
3) Есть ещё варианты?

Я, наверное, неверно выразился. Нужно удалить не сами колонки, а данные из них. Данные секретные. Базу отдаём наружу.

Cловарь оракла - это же и есть достаточно удобный формат хранения структуры таблиц. Весь вопрос - как из него сделать DDL для одной колонки.

Как я понял, dbms_redefinition - это переделка таблицы "на лету", когда с таблицей идёт работа.
Мне же не нужно переделывать таблицу (нужно данные почистить из неё), и в момент моей работы - я буду на базе один, и буду один - сколь угодно долго (неделя - в общем-то тоже возможно, но хочется сократить).
Или dbms_redefinition как-то может помочь в моей задаче?

Скорее не "отдать", а "открыть". Админ остаётся наш.
По ряду причин, нужно отдать максимально тот же самый объём и структуру хранения данных: сегменты, экстенты, итд. Чтобы база была максимально похожей на пром по производительности, но с пустыми (или зашифрованными) секретными данными.

Выдать доступ всем разработчикам, чтобы они могли проверить свой код не только на то,
1) что код работает правильно (для этого есть полупустые тестовые базы),
2) но и на то, что на проме (с его объёмом и структурой хранения данных) код будет работать быстро.

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

1) Это отдельный процесс, которым на проме занимаются отдельные люди.
2) если мы оптимизируем это для тестовой базы (о ней я и вёл речь) при выгрузке через экспорт, дата-памп, или как-то иначе (а на проме останется "как есть", то есть без оптимизации) - то мы рискуем при тестах получить "всё ок, работает", а при накате на пром - положить базу (сильно замедлить её работу).

наша цель: доказать, что при накате на пром очередной доработки, мы не положим пром (в том состоянии, в котором он сейчас есть).

Пусть так. Делать-то что? :)
Пром - большая штука, со своей историей (лет 30 поди уже). На неё постоянно катятся релизы, почти каждый день. Остановить накат релизов, сам понимаешь - невозможно, так как это потерять заказчиков, деньги, и в итоге сам проект.
Вылизать пром до идеального состояния - крайне дорогая и длительная задача. Да и не совсем понятно, возможно ли это.
А положить пром очередным релизом - можно уже сейчас.
Так почему бы не проверить на игрушке, что этот релиз - не убьёт пром? Это понятно, возможно, и не дорого.
Проверять - лучше всего на максимальной копии прома. Потому как ошибки могут быть не только в администрировании, но и в самом оракле.
Чем дальше мы от копии прома - тем больше шанс пропустить ошибку на пром.
Очистка или изменение значения полей - да, мы отдаляем игрушку от прома. Но без этого игрушку никто не выпустит в жизнь.
Изменить структуру хранения таблиц (например экспортом) - это ещё больше отдалить игрушку от прома. Поэтому и не хотим её делать. Да и долго будет. Пересоздать колонку - куда быстрее.