Начало » Использование СУБД » Oracle » SQL*Loader параметры PARALLEL и DEGREE_OF_PARALLELISM
|
|
|
Re: SQL*Loader параметры PARALLEL и DEGREE_OF_PARALLELISM [сообщение #6114 является ответом на сообщение #6113] |
Fri, 13 June 2025 20:43   |
flexgen
Сообщений: 26 Зарегистрирован: July 2022
|
Junior Member |
|
|
Есть два способа загрузки данных при помощи sql loader – conventional path load и direct path load.
CPL является способом загрузки по умолчанию. Описание принципа работы CPL:
Цитата:Conventional path load (the default) uses the SQL INSERT statement and a bind array buffer to load data into database tables. This method is used by all Oracle tools and applications.
When SQL*Loader performs a conventional path load, it competes equally with all other processes for buffer resources. This can slow the load significantly. Extra overhead is added as SQL statements are generated, passed to Oracle, and executed.
The Oracle database looks for partially filled blocks and attempts to fill them on each insert. Although appropriate during normal use, this can slow bulk loads dramatically.
DPL работает иначе:
Цитата:Instead of filling a bind array buffer and passing it to the Oracle database with a SQL INSERT statement, a direct path load uses the direct path API to pass the data to be loaded to the load engine in the server. The load engine builds a column array structure from the data passed to it.
The direct path load engine uses the column array structure to format Oracle data blocks and build index keys. The newly formatted database blocks are written directly to the database (multiple blocks per I/O request using asynchronous writes if the host platform supports asynchronous I/O).
Internally, multiple buffers are used for the formatted blocks. While one buffer is being filled, one or more buffers are being written if asynchronous I/O is available on the host platform. Overlapping computation with I/O increases load performance.
Поскольку CPL выполняет, по сути, обычный insert , то эту операцию можно выполнить параллельно, примерно так же, как это делается с обычным insert:
alter session enable parallel dml;
insert /*+ parallel (a,8)*/ into a
select /*+ parallel (b,8) * from b;
|
|
|
Re: SQL*Loader параметры PARALLEL и DEGREE_OF_PARALLELISM [сообщение #6115 является ответом на сообщение #6114] |
Sat, 14 June 2025 00:24   |
SD
Сообщений: 444 Зарегистрирован: August 2022
|
Senior Member |
|
|
Ну вот в том-то и вопрос: есть в файле записи 1,2,3...10. Загрузка идёт с DEGREE_OF_PARALLELISM=2, то есть в две сессии. Будут записи 1,2,3,4,5 вставлены в одной сессии, а 6,7,8,9,10 - в другой? Или в одной сессии будут 1,3,5,7,9, а в другой 2,4,6,8,10?
|
|
|
Re: SQL*Loader параметры PARALLEL и DEGREE_OF_PARALLELISM [сообщение #6116 является ответом на сообщение #6115] |
Sat, 14 June 2025 22:24   |
flexgen
Сообщений: 26 Зарегистрирован: July 2022
|
Junior Member |
|
|
SD писал(а) Sat, 14 June 2025 00:24Ну вот в том-то и вопрос: есть в файле записи 1,2,3...10. Загрузка идёт с DEGREE_OF_PARALLELISM=2, то есть в две сессии. Будут записи 1,2,3,4,5 вставлены в одной сессии, а 6,7,8,9,10 - в другой? Или в одной сессии будут 1,3,5,7,9, а в другой 2,4,6,8,10?
Я думаю что во время выполнения параллельного INSERTа вычисляется некий хэш, допустим, при помощи функции ORA_HASH, скажем, по первому значению. И INSERT выполняется по условию WHERE MOD(ORA_HASH(:B1),< DEGREE_OF_PARALLELISM >) = 0 (1,2,3...N)
Допустим, мы делаем вставку 1 миллиона записей, и выполняем его со значением DEGREE_OF_PARALLELISM=2. Тогда этот 1 миллион записей будут распределен на 2 части, со значением MOD(ORA_HASH(:B1)) равным 0 и неравным 0. Все записи, у которых значение хэша равно 0 обрабатывает первый процесс, все остальные - второй.
|
|
|
|
Re: SQL*Loader параметры PARALLEL и DEGREE_OF_PARALLELISM [сообщение #6119 является ответом на сообщение #6117] |
Sun, 15 June 2025 10:51  |
flexgen
Сообщений: 26 Зарегистрирован: July 2022
|
Junior Member |
|
|
SD писал(а) Sun, 15 June 2025 00:47На первый взгляд звучит неплохо, но меня терзает смутное сомнение: если коммит первой сессии прошёл, а второй - обломался по любой причине, мы получаем базу в которую загрузилась только половина записей из файла и без хрустального шара не угадать каких записей не хватает?..
Мы имеем дело с одной транзакцией, которая выполняет два параллельных процесса вставки данных. И если есть какая-либо проблема, то оба процесса останавливаются, и для транзакции выполняется rollback. Соответственно, данные не загрузятся вообще. Если же все прошло нормально, то для транзакции будет выполнен commit.
|
|
|
Переход к форуму:
Текущее время: Sun Jun 15 17:02:25 GMT+3 2025
Общее время, затраченное на создание страницы: 0.01259 секунд
|