большое движение данных

Я хотел бы переместить миллиарды строк из schema1.table1 в новую schema2.table2, где table2 является рефакторированным из table1. Следовательно, их структура таблицы отличается. и table1, и table2 разделены, но table2 пуст. Обе эти схемы находятся в одной и той же оракулярной базе данных. Каков эффективный способ выполнения этой миграции данных? Вы хотите выполнить коммит только в самом конце или выбрать инкрементный коммит? т. е., скажем, перенос данных не выполняется после выполнения 99% задания, которое заняло несколько часов. Откатываете ли вы сейчас? Если вы делаете добавочный коммит, как вы справляетесь с ошибкой?

Параллельно INSERT APPENDс NOLOGGINGбудет способ сделать это, тогда как со всеми операциями NOLOGGING, сделайте резервную копию сразу по завершении. Сначала пометьте индексы как непригодные для использования, отключите ограничения, измените таблицу, выполните операцию, затем повторно включите ограничения и т. Д.

Добавление заставляет Oracle всегда захватывать свободное пространство выше текущей верхней отметки, поэтому неэффективно повторно использовать пространство в сегменте, но избегает суеты с фрилансом и накладными расходами UNDO. Если по какой-либо причине вам придется начинать заново TRUNCATE, не надо DELETE.

Что касается добавочного коммита, то это будет зависеть от того, как сегментируются ваши данные, можете ли вы легко сказать, перемещать ценность за месяц за раз (например, одинакова ли схема разделения в исходном и целевом объектах)? Потому что помните, что если вам нужно удовлетворить какой-то предикат, это, очевидно, замедлит вас. Протестируйте, чтобы убедиться, что операция не будет иметь логического сбоя (например, несовместимые типы данных в источнике и цели), затем выделите достаточные ресурсы и просто сделайте это в одной транзакции. Удачи!

если схема разделов одинакова (данные раздела a в таблице 1 идут в раздел a в таблице 2 и т. д.), то я бы пошел на несколько сеансов, и каждый сеанс добавлял свои данные в свой «собственный» раздел. Это предотвращает много блокировок и имеет лучшую скорость. В зависимости от аппаратного обеспечения вы можете заполнить карты HBA до шеи. Фиксация для каждого раздела - при условии, что для каждого раздела будет несколько строк, - не будет проблемой, и я бы, конечно, сделал это. Предполагая, что приложение не работает во время миграции, запасной вариант прост: не меняйте приложение и не обрезайте разделы таблицы 2 перед повторной попыткой, по крайней мере для тех частей, где приложение изменило данные до того, как может произойти второй запуск.

надеюсь, это поможет