Комментарии 7
С дебютом ))
Спасибо за статью.
Вариант с голденгейтом не рассматривали?
Ну т.е.: слепить, какую надо, целевую таблицу, с какими надо индексами, грантами.
И запустить на неё репликацию из исходной (старой) таблицы.
Когда среплициуются все, или, хотя бы - какие надо строки, собрать цбо-стату на новую таблицу, выставить лок на старую таблицу, репликацию остановить, старую таблицу переименовать, создать синоним на новую таблицу, провайдящий старое имя, доработать целевую таблицу (триггеры например, если надо, создать) валидировать всё что развалидось от удаления старой таблицы.
Привет, коллега!
Вариант из топика применялся на боевой задаче? Сколько по времени заняло такое создание чанков? Мне всегда казалось что в этом случае СУБД будет фуллсканить таблицу-источник:небыстрый вариант для непараллельного режима.
А почему секционирование по номеру, а не по дате изменения, например? В дальнейшем не планировалось поддерживать глубину хранения в 3 года?
Да, это вполне пром задача, правда с некоторыми изменениями, исходная чуть шире.
Отдельно чанкование не смотрела, весь перенос целиком - 1 час 30 минут 17 секунд. Создание чанков не фулсканит таблицу при чанках по ROWID.
Не по дате - поскольку запросы к таблице не содержат дат, зато поголовно содержат выбранный ключ партиции. А поле генеримое из сиквенса при наличии поля created позволяет легко поддерживать нужную глубину.
а для 11g подойдёт этот способ?
Oracle. Ещё один способ партиционирования больших и нагруженных таблиц