Как я могу ускорить загрузку данных в таблицы Oracle? - PullRequest
0 голосов
/ 04 октября 2011

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

Один человек сказал что-то о предварительной подготовке таблиц, и это каким-то образом могло ускорить процесс.,Я не знаю, что это такое, и может ли это помочь.Я надеялся на вклад.Спасибо.

Oracle 11g - это то, что используется.

update: моя база данных кластеризована, поэтому я не знаю, могу ли я что-нибудь сделать, чтобы ускорить процесс.

Ответы [ 3 ]

2 голосов
/ 04 октября 2011

Что вы можете попробовать:

  • отключение всех ограничений и включение их только после процесса загрузки
  • CTAS (создать таблицу как выбранную)

Что вы действительно должны сделать: понять, что вы узкое место.Это сеть, файловый ввод / вывод, проверка ограничений ... затем исправьте эту проблему.Для меня рассмотрение плана объяснения в большинстве случаев является первым шагом.

1 голос
/ 04 октября 2011

Какую конфигурацию вы используете? Имеет ли база данных, куда импортируются данные, нечто вроде резервной базы данных, связанной с ней? Если это так, то вполне вероятно, что конфигурация с включенным force_logging включена? Вы можете проверить это, используя

SELECT FORCE_logging from v$database;

Его также можно включить на уровне табличного пространства:

SELECT TABLESPACE_name,FORCE_logging from DBA_tablespaces

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

SELECT LOG_mode from v$database;

Если это так, возможно, архивы написаны недостаточно быстро. В этом случае увеличьте размер онлайн-файлов редологов. Если база данных не работает в режиме архивного журнала, она все равно должна выполнять запись в файлы повторного выполнения, если не используется прямая вставка пути. В этом случае проверьте, насколько быстро могут быть написаны повторы. Обычно 200 ГБ / ч вполне возможны, когда индексы не играют роли.

Важно найти, какая ссылка вызывает нехватку производительности. Это может быть вход, это может быть выход. Здесь я сосредоточился на выводе.

1 голос
/ 04 октября 2011

Как предположил Йенс Шаудер, если вы сможете подключиться к своей исходной системе через соединение с БД, CTAS станет лучшим компромиссом между производительностью и простотой, если вам не нужны какие-либо объединения на стороне источника.

В противном случае вам следует рассмотреть возможность использования SQL * Loader и настройки некоторых параметров.Используя прямой путь, я смог загрузить 100M записей (~ 10 ГБ) за 12 минут на 6-летнем ProLaint.

EDIT: Я использовал формат данных, определенный для эталонного теста сортировки Datamation.Генератор для него доступен в дистрибутиве Apache Hadoop.Он генерирует записи с полями фиксированной ширины с 99 байтами данных плюс символ новой строки в каждой строке файла.Файл управления SQL * Loader, который я использовал для чисел, указанных выше:

OPTIONS (SILENT=FEEDBACK, DIRECT=TRUE, ROWS=1000)
LOAD DATA
INFILE 'rec100M.txt' "FIX 99"
INTO TABLE BENCH (
BENCH_KEY POSITION(1:10),
BENCH_REC_NBR POSITION(13:44),
BENCH_FILLER POSITION(47:98))
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...