Задача при миграции огромного стола с данными LOB

Question

Мы пытаемся перенести около 230 ГБ базы данных Oracle EC2, размещенной в RDS. Задача с БД состоит в том, что есть одна таблица 150 ГБ, в которой много данных LOB. Когда мы пытаемся выполнить миграцию данных с использованием Oracle Import/Export (Data Pump), для экспорта таблицы 150 Гбайт требуется около 9,5 часов, и у них есть данные LOB и 2 часа для импорта дампа в RDS, тогда как другие таблицы довольно быстро мигрировали. Мы используем экземпляр с наивысшими конфигурациями, но не видим улучшения в производительности.

Просто, чтобы увидеть разницу во времени, выгрузили сброс 150 ГБ на EC2, а во втором - потребовалось всего 3 часа. Может кто-нибудь, пожалуйста, предложите мне лучший подход к сокращению времени экспорта/импорта.

PS: Мы также попытались использовать средство RedGate для определения различий между схемами и данными между базами данных Oracle, но этот инструмент также не смог выполнить сравнение на огромных таблицах больших объектов.

Answer 1

Быстрый способ я нашел, чтобы перенести большие объемы LOBs следующим образом:

Экстракт

• Написать выписку клиента (Java), который будет обрабатывать заданный диапазон ID значений.
• Запишите данные, отличные от LOB, для каждой строки в качестве CSV, а LOB - как файл и укажите файл в CSV для каждой строки.
• Запускайте столько выходов параллельно (это внешние процессы Java, поэтому их нельзя блокировать ограничениями Oracle по вашей лицензии)
• Желательно написать извлечение в файловую систему, которая может «размахиваться» между двумя серверами. Если возможно, столько файловых систем, сколько у вас есть процессов параллельного извлечения.

нагрузки

• Использование SQLLoader. Он имеет возможность

  image_fname ФИЛЛЕР CHAR (80), изображение LOBFILE (image_fname) TERMINATED BY EOF

• Эксперимент с DIRECT = Y - на некоторых версиях (10 г), я нашел, что это немного ненадежны, и получил в моем проекте происходит сбой регулярных сообщений, но он может быть улучшен с этим типом нагрузки.

• Опять же, используйте параллельные процессы загрузчика sql, где это возможно - вы можете отключить ограничения и индексы или использовать обратные индексы, чтобы уменьшить конфликт блоков для параллельных нагрузок.

Вы можете рассмотреть возможность разбиения на цель и параллельной загрузки каждого раздела.

Преимущество использования «размахивающих» файловых систем заключается в том, что вы устраняете узкие места в сети.

Эти примечания являются общим руководством, а не конкретным, и для получения оптимального сочетания потребуются некоторые настройки и эксперименты.

Answer 2

Что касается вашего примечания PS об использовании RedGate для сравнения данных, я предполагаю, что это для сверки данных.

Опять же, я могу дать общее руководство, но при моей последней миграции у меня были терабайты данных для сравнения, а использование традиционной отчетности на диске и различие было слишком медленным, и у нас не было достаточно диска.

Так что я сделал писать Java (потому что он, как правило, на сервере Oracle, и вы действительно хотите работать на на е серверов, чтобы свести к минимуму узких мест в сеть) программы, которая сделала следующее:

• Открыть JDBC-соединение с обеими баз данных
• Указать таблицу для обработки, а также диапазон идентификаторов, а также размер партии
• прочитанной строка в заданном диапазоне гнева ID из таблицы и заполнить область памяти с размером партии - Я использовал java.util.concurrent.ArrayBlockingQueue и java.util.concurrent.BlockingQueue объекты
• Использование потоков для чтения данных из обеих баз данных
• Когда обе очереди заполнить Выполнить сравнение на 2 очереди

Что касается сравнения сгустков, подход, который я взял был использовать DBMS_CRYPTO хэш значения LOB и Сравните их. Это уменьшает количество данных, считываемых на Java. Любые различия были выделены для дальнейшего изучения.

Очевидно, что, будучи внешним процессом Java, он может работать параллельно до оптимального числа. Этот метод оказался быстрее, чем другие доступные нам инструменты.

В этом проекте я обнаружил, что Oracle предоставляет новый пакет под названием DBMS_COMPARISON. Возможно, это стоит того, чтобы посмотреть на это. Я ищу возможность сравнить это с моим пользовательским решением.