kT_________,

В темпспейсе будет формироваться таблица и индексы в новом "хорошем" виде. Потом копироваться обратно.

Может быть супер-эффективно, если темпспейс на другом девайсе, а на исходное - не SSD based (одновременное чтение/запись сильно тормозят общий transfer rate).

Можете запустить и так и так, и посмотреть, что будет идти на первых фазах reorg'а (sort/build) с помощью:
и решить, что будет быстрее.
Предположение - копирование обратно должно производиться экстентами == потоковым чтением-записью, т.е. существенно быстрее, чем собственно сам "reorg" таблицы, действительно в операции reorg нуждающейся.


Второй момент.
При использовании темпспэйса последующее копирование производится _поверх_ существующей таблицы == не требует дополнительного пространства в размере самой таблицы в исходном tablespace (что важно для сверхбольших таблиц).

При реорге "на месте" обратное копирование не производится, а просто производится "подмена". В DMS табличных пространствах при этом остаётся свободное место в начале пространства (если экстенты исходно были "плотно упакованы"), которое, впрочем, при желании тоже можно отдать системе - LOWER HIGH WATER MARK + (когда extent'ы смувятся) REDUCE MAX;

kT_________Только вот про индексы, я то думаю если я просто поля добавляю и они не индексными будут, то мне достаточно реорга таблички, и не надо делать reorg indexes for table <Tab>, достаточно reorg table <Tab>, верно?
Нет, неверно. Реорг изменяет порядок расположения строк в таблице и/или их расположение в страницах, поэтому при реорганизации таблиц реорг индексов выполняется всегда (отдельной фазой реорга). Индексы при этом просто полностью перестраиваются заново.

Что бы было побыстрее я распараллеливаю реорг табличек, и делаю например пачками, это чревато??
т..е может ли например нехватить места в тейблспейсах при таком подходе?
Не хватить места - ну да, может. Все данные для правильной калькуляции у Вас в руках.
Основная фаза реорганизации (build)... Я бы предположил, что теоретически параллельное чтение из нескольких таблиц при правильно выбраном размере экстента (если чтение при реорге происходит экстентами (тут вупрос к Марку)) в лучшем случае не будет замедлять общего transfer rate.

Тем не менее, практика - критерий истины. Запустите один реорг (с долгими реоргами у вас проблем быть не должно ;)), затем добавляйте по одному и смотрите, пока общая скорость по CurCount в фазе Build не выйдет на порог насыщения (по "db2pd -db <dbname> -reorgs"). Получите оптимальное количество параллельно выполняемых реоргов. Вполне возможно это будет 1 (т.е. быстрее выполнять будет строго последовательно).

вероятно если я не указываю для реорга темпспейс какой-то особенный, то он использует по умолчанию.. и тогда если идет параллельный реорг, то тоже и не хватить этого темпспейса, всё так?
Нет. Если не использовать USE clause, то при при reorg'е таблица (как и индексы) складываются в текущее же табличное пространство ("рядом" с другими таблицами/данными).


PS Полезый запрос по LARGE табличным пространствам:


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