великий рух даних

Я хотів би перемістити мільярди рядків з schema1.table1 до нової схеми2.table2, де table2 є переробленим з таблиці1. Отже, їх структура столів різна. і table1, і table2 є розділеними, але table2 порожній. Обидві ці схеми знаходяться в одній БД Oracle. Який ефективний спосіб ефективної міграції даних? Чи хочете Ви виконувати фіксацію лише в самому кінці, або вибираєте додаткову фіксацію? Скажімо, міграція даних не вдається після виконання 99% роботи, яка займала кілька годин. Ви відкатуєтесь зараз? Якщо ви робите поступовий вчинок, як ви впораєтеся з невдачею?

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

Додаток змушує Oracle завжди захоплювати вільний простір над поточним знаком високої води, тому він не є ефективним для повторного використання простору на сегменті, але це дозволяє уникнути спонукання з фрілістом та UNDO накладними. Якщо вам доведеться починати заново з будь-якої причини, TRUNCATEне робіть цього DELETE.

Що стосується додаткової комісії, то це залежатиме від того, як сегментуються ваші дані, чи можна легко сказати, що варто рухатись на місяць за один раз (наприклад, схема поділу однакова як у джерелі, так і в цілі)? Тому що пам’ятайте, що якщо вам потрібно задовольнити якийсь присудок, це, очевидно, сповільнить вас. Перевірте, чи впевнено операція не виходить з ладу (наприклад, несумісні типи даних у вихідному та цільовому), тоді виділіть достатню кількість ресурсів та просто перейдіть на неї за одну транзакцію. Удачі!

якщо схема розділів однакова (дані поділу a в таблиці 1 переходять до розділу a в таблиці 2 тощо), я б ходив на кілька сеансів і мав би кожен сеанс додавати свої дані у свій "власний" розділ. Це запобігає сильному блокуванню і має найкращу швидкість. Залежно від обладнання ви можете заповнити картки HBA аж до їх шиї. Комісія для кожного розділу - припускаючи більше декількох рядків для кожного розділу - не буде проблемою, і я, безумовно, це зробив. Якщо припустити, що програма під час міграції не працює, резервна копія проста: не змінюйте додаток і вкорочуйте розділи таблиці2, перш ніж повторити спробу, принаймні для тих частин, де додаток змінив дані до того, як може відбутися другий запуск.

Я сподіваюся, що це допомагає