Leonid VorontsovЕсли я что-то понимаю в этом деле, такие внутренние вещи совершенно не докуметированы, поэтому поможет только эксперимент (наверное, к сожалению). Например, не очень давно я менял паре десяков таблиц тип первичного ключа (INT не хватило), а с ним и все REFERENCES на DEC( 12, 0 ), так знаешь, результат превзошёл все ожидания (я тоже использовал ALTER MODIFY) - на миллионных таблицах всё произошло практически мнгновенно! Но и размеры таблиц никак не изменились. А вот, помню, приходилось менять CHAR на VARCHAR (или наоборот, уже не помню), так это просто кирдык - до трёх суток один ALTER работал - зато фрагментация идеальная! :-) Так что...
Как раз достаточно неплохо документировано. Как минимум читай все то же приведенное Выбегалло
ВыбегаллоПочитайте performance Guide, раздел Altering a Table Definition
Altering a Table Definition
The database server uses one of several algorithms to process an ALTER
TABLE statement in SQL:
n Slow alter
n In-place alter
n Fast alter

Поэтому и твои результаты конвертации сильно отличались по времени, так как в одном случае все изменения происходили только в описании таблицы и физически ее страницы не перезаписывались (это перезаписывание просто отложено во времени и будет происходить по мере обычной модификации страниц и т.о. одновременно будут существовать разные версии страниц одной таблицы), а в другом случае требовалась полная перезапись всех страниц таблицы.
Если в первом случае (In-place alter) есть время и желание привести все страницы к одной структуре то:
Выбегалло... для полной модицикации надо запустить что-то типа update table where a=a ).
Хотя я обычно предпочитаю init fragment в тот же самый dbspace.

cprага init fragment рулит, но на не очень больших объемах.
А что такое "не очень больших объемах" ?
И почему ?

cpr[Дело в том, что альтер фрагмент по видимому полностью перестраивает индексы (или перепроверяет). Во всяком случае наблюдение за поведением сервера наводит именно на эти мысли т.к. сначала идет чтение из чанков старого дбспэйса в новое, а затем ситывание уже перенесенных данных и сортировки.
Конечно же, индексы перестраиваются, ведь данные физически изменяют свое местоположение. Но зачем же перестраивать индексы все время ? Значительно проще выключить индексы на период перезаписи и затем включить, для однократной перестройки. Будет значительно быстрее.
Конечно же, онлайновый режим работы (системы в целом) страдает, но то же самое получится и при выгрузке-загрузке.
К сожалению, уже упомянутая проблема длинной транзакции значительно более тяжелая и о ней я успел забыть (спасибо Тане за напоминание).

cpr vasilis
Значительно проще выключить индексы на период перезаписи и затем включить, для однократной перестройки. Будет значительно быстрее.

Выключить, это значит сделать drop index ?
Т.е. сначала дропнуть индексы, затем сделать альтер фрагмент и создать их?
Нет, конечно. Я же написал "выключить", т.е. сделать
Выключаться все неавтоиндексы. Соответственно, для оставшихся нужно, опять таки, выключить (а не дропнуть) соответствующие констрейнты.
А дропнуть в переводе на русский звучит как "удалить".