Larry E.,

А из чего видно, что он пошёл сначала быстренько?
- load виден в "db2 list utilities show detail"
- видно по мониторам сколько select нафетчил
- .....

Larry E.,

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

Если с вводом/выводом в системе всё хорошо (соответствующие диски нагружены), то я бы посмотрел на статистику по buffer pool logical/physical reads индекса(ов) target таблички - POOL_INDEX_L_READS/POOL_INDEX_P_READS MON_GET_CONNECTION() (или на уровне табличного пространства/UOW)

Если POOL_INDEX_P_READS велико (в динамике), плюс ROOT_NODE_SPLITS и INT_NODE_SPLITS ( MON_GET_INDEX() ) существенны, то вполне возможно, тормоза - следствие опции COPY_WITH_INDEXES.
С какого-то момента массовый insert порождает существенную работу по перестроениям индекса.
Если параметр LOGINDEXREBUILD не включён (что может потребоваться для HADR конфигурации), то лучше опцию убрать и построить индексы после. Вообще, индексов на таблице много?

Другой вариант - таблица упёрлась в размер табличного пространства, а INCREASESIZE у него очень мал.


BTW А почему не используется COPY_USE_LOAD опция? Это будет не на один порядок быстрее.

Larry E.,

Ну вот оно явно при вставке использует первый индекс. Он, надо полагать, уникальный.
Т.е. при вставке на каждую строку необходимо найти соответствующую страницу в индексе, вытащить, возможно разделить на две, и сделать туда вставку.
С какого-то момента индекс мог перестать влезать в буфферпул и начать сам себя вытеснять при работе, что должно приводить к увеличению физических чтений страниц индекса (POOL_INDEX_P_READS) и соответствующему резкому замедлению процесса вставки.

Вопрос, кстати, достаточно ли ADMIN_MOVE_TABLE() сообразительна, чтобы на время загрузки переключить таблицу в APPEND mode (можно посмотреть db2look'ом, примерно так - "db2look -d <dbname> -e -t SAPERP.CKMI1AASAHBs -nofed -o SAPERP.CKMI1AASAHBs.ddl").
Боюсь, что недостаточно, что тоже увеличит время вставки.

Можно попробовать увеличить буфферпул, в котором живут индексы новой таблицы.
Но правильней, конечно, остановить это недоразумение и перезапустить с опцией COPY_USE_LOAD. Все большие таблицы стоит копировать только так. Если нет планов сразу после копирования делать бэкап базы, то использовать дополнительно COPY YES ....
COPY_WITH_INDEXES оставить - LOAD индексы в один проход во временных табличных пространствах строит, потом поочереди целиком копирует.
Время копирования будет раза в два больше, чем



Или раз в 20 дольше


fetch first, наверное, лучше использовать, чем TABLESAMPLE clause, поскольку тот работает или на уровне строк или страниц, что, возможно, не даст включиться механизму prefetch и выдаст неверное время.
Если строки по таблице сильно отличаются в размере, то лучше "TABLESAMPLE SYSTEM (10)", но это, кстати, теоретически тоже может быть причиной изменения скорости копирования.

Можно попробовать не прерывая текущего копирования, что грубо даст оценку времени (даст понять, стоит ли ждать ещё с месяц).

PS В таблице есть LONG/LOB поля? Таблица партиционированная? Компрессированная?

Larry E.,

Удаление индекса скорее всего вернёт начальную скорость.
Но по завершении admin_move_table переименовывает индексы в соответствии с их оригинальными именами. Что произойдёт, когда оно индекса не обнаружит, сказать сложно, поэксперементируйте где-нибудь с небольшой табличкой.

CLUSTERRATIO сам по себе не будет хорошим, если на исходной таблице не было кластерного индекса. Если нету, то необходимо процесс копирования/move разбивать на фазы INIT/COPY/REPLAY/SWAP, и после INIT с помощью ADMIN_MOVE_TABLE_UTIL() указывать схему и имя индекса, по которому будет производиться упорядочивание. Это, соответственно, замедлит перенос.

PS Я бы ещё раз порекомендовал подумать об использовании LOAD'а.