greifeld,

У вас все таблицы/индексы в одном tablespace ? Это не есть хорошо. Для крупных таблиц/индексов желательно индивидуальные TS.

ИМХО вначале полноценно смигрировать в 9.7, потом создать дополнительные tablespace с нужным размером страницы и туда "увести" крупные таблицы/индексы постепенно.
В 9.7 для этого есть процедура ADMIN_MOVE_TABLE procedure - Move tables online .

CawaSPbЕвгений Хабаров,

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

CawaSPbЕвгений Хабаров,

Если есть необходимость сократить время переключения (а можни считать априори, что такая необходимость есть), то можно:
а) дозаливать итеративно только изменяющиеся таблицы (отслеживая, к примеру, по изменениям в результатах MON_GET_TABLE(...) значений rows_inserted, rows_updated, rows_deleted). Во множестве случаев в период низкой нагрузки этого хватит.
б) в конце концов просто настроить Q репликацию (запретив нелогирумые операции).

Важно при этом, чтобы за период миграции никто "чужой" структуру базу не правил, но это вообще правильно и, в крайнем случае отслеживаемо (с 10.1 Q репликация и изменения структуры реплицировать умеет, но я бы на это не полагался).

Но да, нужны предварительные репетиции.
Могу только согласиться. :)
Собственно задача миграции это особый процесс, требующий проектирования и планирования. И хорошо, что есть несколько вариантов и пространство для маневра.

greifeldЕщё admin_move_table судя по всему не понимает пользовательские типы данных
А также ругается, если в комментариях в столбцам таблицы есть запятая... Это тихий ужас.

Зачем она вообще нужна с такими ограничениями?
Для случаев, когда не натыкаешься на ограничения, или же натыкаешься, но на малом проценте таблиц.
Запятая в комментариях - это похоже на баг. Фикспак какой стоит?
На этой же хранимой натыкались на проблему на одном из ранних фикспаков - давало ошибку переноса, если на таблицу были выданы права для идентификатора "PUBLIC".

greifeldAndronА вообще, начиная с версии 9 в db2 все tablespace создаются как large, т.е. при том же размере страницы что и в 8 версии, ограничения на размер tablespace более чем приемлемые для большинства систем:

Table space type4K page size limit8K page size limit16K page size limit32K page size limitDMS and nontemporary automatic storage table spaces ( regular )64G128G256G512GDMS and temporary DMS and nontemporary automatic storage table spaces ( large )8192G16 384G32 768G65 536G

Но после миграции с 8 на версию 9 надо сделать конвертацию с помощью ALTER TABLESPACE tablespace_name CONVERT TO LARGE

Поэтому наверно проще сделать миграцию а затем сконвертировать пользовательские tablespace чем заниматься потабличным переносом :)

Это был бы просто шикарный вариант, если бы не:

db2 => ALTER TABLESPACE DATASPACE CONVERT TO LARGE
SQL1237W Для табличного пространства "DATASPACE" выполняется преобразование
из типа REGULAR в тип LARGE. Нужно реорганизовать или перестроить индексы для
таблиц в этом табличном пространстве для поддержки больших RID.
SQLSTATE=01686

Все индексы я реорганизовывал сразу после миграции на 9.7.
В руководстве не вижу пока ключей для какой-то особенной реорганизации "для поддержки больших RID"

SQL1237W - это не ошибка, а предупреждение. Смотрим внимательно описание сообщения.
А далее читаем описание опции CONVERT TO LARGE в разделе ALTER TABLESPACE statement
Там написано следующее:Раздел NotesConversion to large DMS table spaces: After conversion, it is recommended that you issue the COMMIT statement and then increase the storage capacity of the table space.

If the table space is enabled for auto-resize, the MAXSIZE table space attribute should be increased, unless it is already set to NONE.
If the table space is not enabled for auto-resize:
Enable auto-resize by issuing the ALTER TABLESPACE statement with the AUTORESIZE YES option, or
Add more storage by adding stripe sets, extending the size of existing containers, or both

Indexes for tables in a converted table space must be reorganized or rebuilt before they can support large record identifiers (RIDs).

The indexes can be reorganized using the REORG INDEXES ALL command (without the CLEANUP ONLY clause). Specify the ALLOW NO ACCESS option for partitioned tables.
Alternatively, the tables can be reorganized (not INPLACE), which will rebuild all indexes and enable the tables to support more than 255 rows per page.

To determine which tables do not yet support large RIDs, use the ADMIN_GET_TAB_INFO table function.