|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
Скажите пожалуйста, каким алгоритмом можно наиболее быстро можно загрузить 170 000 000 строк из Oracle в MSSQL при помощи SSIS пакета? Заранее благодарен. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2020, 02:01 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
Загрузить - BCP.exe. Быстрее не бывает. А вот выгрузить - проблема. Это у оракелистов надо спрашивать. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2020, 06:58 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
170 000 000 строк я бы упомянул если речь идет о выборке или поиске Переливаете же вы все 170 000 000 строк, поэтому скорее важен размер данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2020, 07:14 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
Тут возможно узким местом будет сеть между серверами. Поэтому искать перфекционизма а не стоит. А стоит просто посмотреть каким маршрутом польется информация и как этот маршрут можно выпрямить. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2020, 12:16 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
vah, Быстро можно загрузить многопоточной загрузкой в пустую таблицу без индексов. Увеличивайте количество потоков, пока скорость загрузки не прекратит расти. Как только прекратит - значит вы уперлись в, скорее всего, сеть, диски приемника, диски источника ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2020, 12:36 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
vah, Using SSIS to load 1TB data into SQL Server in 30 mins, with simplified settings Основное: настроить правильный размер буфера во избежание дискового обмена, секционировать таблицы и загружать секции параллельно. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2020, 12:42 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
.Евгений vah, Using SSIS to load 1TB data into SQL Server in 30 mins, with simplified settings Основное: настроить правильный размер буфера во избежание дискового обмена, секционировать таблицы и загружать секции параллельно. Дык, фся эта возня с настройками, секционированием и т.д. и т.п. займет больше времени, чем однопоточная вставка в простую таблицу. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2020, 12:51 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
aleks222 Дык, фся эта возня с настройками, секционированием и т.д. и т.п. займет больше времени, чем однопоточная вставка в простую таблицу. Может быть. Но на простой вопрос - простой ответ. Не вижу смысла гадать по юзерпику, какую задачу на самом деле ему надо решить. Или, тем более - внушать, что задачу нужно решать не эту, а совсем другую. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2020, 13:24 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
vah Скажите пожалуйста, каким алгоритмом можно наиболее быстро можно загрузить 170 000 000 строк из Oracle в MSSQL при помощи SSIS пакета? Заранее благодарен. Если это разовое действие , то согласен с aleks222 .Евгений vah, Using SSIS to load 1TB data into SQL Server in 30 mins, with simplified settings Основное: настроить правильный размер буфера во избежание дискового обмена, секционировать таблицы и загружать секции параллельно. Дык, фся эта возня с настройками, секционированием и т.д. и т.п. займет больше времени, чем однопоточная вставка в простую таблицу. Если это периодически, то прежде всего оценивайте объём данных: Вам написали : PizzaPizza 170 000 000 строк я бы упомянул если речь идет о выборке или поиске Переливаете же вы все 170 000 000 строк, поэтому скорее важен размер данных. Ибо если у Вас одна таблица в пару столбцов int , то это всего 700 МБ данных (примерно), и вопросов нет. Но если записи по 1К (и выше) на запись, то уже да,- тут стоит смотреть и сеть, и систему хранения... И алгоритм заливки... PS Кстати, если система хранения одна (без разницы - это "полка" или RAID), то с точки зрения самой системы хранения,- абсолютно пофиг на секционирование - т.к. "физически" данные польются через один канал на один набор дисков (если они сконфигурированы в общий набор , который потом порезан на логические юниты). Но это моё мнение. Но вопрос о конфигурации системы хранения НЕ стоит игнорировать. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2020, 13:28 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
PizzaPizza, выборка, без условий, около 20ти столбцов, есть varchar-ы ( ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2020, 15:23 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
vah, BULK INSERT чем не устраивает? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2020, 18:27 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
с одной стороны конечно varcharы хорошо бы нативно перекинуть SSISом, а не балком через файл с другой стороны, раз они из оракла, то я бы все равно подумал бы о кодировках и прочем даже при использовании SSIS ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2020, 20:01 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
vah PizzaPizza, выборка, без условий, около 20ти столбцов, есть varchar-ы ( Если твоя задача - одноразовая то сделай любым способом экспорт в CSV и потом импорт в другую БД. Если будешь делать на постоянной основе - тогда расскажи форуму о статистике. Тоесть какая будет длина этого CSV файла. Какая средняя длина строки в байтах. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2020, 20:24 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
vah PizzaPizza, выборка, без условий, около 20ти столбцов, есть varchar-ы ( ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2020, 22:59 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
vah, 0. Разово или постоянно? 1. Есть ли секционирование на источнике или иная возможность быстро получить в параллель непересекающиеся множества? 2. В каком виде предоставлен доступ к источнику данных? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.08.2020, 09:55 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
andreymx, Там же версионник, главное на snapshot too old при select .. as of timestamp не влететь ... |
|||
:
Нравится:
Не нравится:
|
|||
10.08.2020, 09:55 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
env andreymx, Там же версионник, главное на snapshot too old при select .. as of timestamp не влететь хотя вдруг там экзадата со всем фаршем? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.08.2020, 10:15 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
andreymx, Обычный DataFlow из источника в назначение. Поставить опции fastload и размер порции не менее 100000. Можно 500000. Драйвера на Oracle OLEDB , на MSSQL SQL Native Client или тоже OLE DB. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.08.2020, 12:21 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
на самом деле 170 млн строк не так уж и много тут еще вопрос уже поднимали насчет пропускной способности сети и еще могут быть тормоза, если сервер оракл на земле, а сервер мсскл в ажуре (или наоборот) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.08.2020, 12:56 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
для SSIS был драйвер Attunity для оракла но там надо версии смореть - последний раз я юзал его для 2014 - по моему версия 3.0 выигрыш по скорости был и приличный. если грузить через что-то - я бы грузил через csv файлы (скажем по месячно) с трудом представляю себе один CSV файл такого размера (не утверждая что это не возможно) опять же возможно вставлка по месячными партициями - если они есть на такой таблице посмотрел еще раз SSIS ну так загрузили 1 день (1 неделю) (1 месяц) - проверили данные - кодировку и пустили потом в цикле запросы и запись (либо сразу в таргет таблицу либо во временные промежуточные ) надеюсь что индекс по дате (последнего апдейта )в оракле есть (иначе сложно) если вдруг нет - посмотрел бы можно заюзать другой индекс - но это хуже ну и путем экспериментов нашли оптимальное решение под себя. зы можно еще линк-сервер - но это точно медленней - хотя я грузил приличные объемы данных ночью кусочками по 2-3 дня удобней что можно в t-sql написать цикл и просто гнать но тогда нагрузки на оракл-сервер другой не было ... |
|||
:
Нравится:
Не нравится:
|
|||
10.08.2020, 13:24 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
andreymx на самом деле 170 млн строк не так уж и много тут еще вопрос уже поднимали насчет пропускной способности сети и еще могут быть тормоза, если сервер оракл на земле, а сервер мсскл в ажуре (или наоборот) Надо сразу писать инкрементальную загрузку. Чтобы она продолжала с того места, где закончила. Надеяться, что 170 лямов пройдут за один заход не стоит. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.08.2020, 14:36 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
a_voronin Чтобы она продолжала с того места, где закончила Что, к сожалению, возможно далеко не всегда. Особенно, если источник не предполагает сообщать об обновлениях и, что ещё хуже, удалениях. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.08.2020, 15:53 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
env a_voronin Чтобы она продолжала с того места, где закончила Что, к сожалению, возможно далеко не всегда. Особенно, если источник не предполагает сообщать об обновлениях и, что ещё хуже, удалениях. гадать не перегадать ... |
|||
:
Нравится:
Не нравится:
|
|||
10.08.2020, 16:00 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
env a_voronin Чтобы она продолжала с того места, где закончила Что, к сожалению, возможно далеко не всегда. Особенно, если источник не предполагает сообщать об обновлениях и, что ещё хуже, удалениях. При любом раскладе есть решение через доп таблицу и триггер на источнике. На Oracle они не так сильно тупят как на MSSQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.08.2020, 16:06 |
|
Загрузка 170 000 000 записей
|
|||
---|---|---|---|
#18+
a_voronin При любом раскладе есть решение через доп таблицу и триггер на источнике. На Oracle они не так сильно тупят как на MSSQL. Ага, поставьте триггер на таблицу в первичной банковской системе... Часто проще грузить по 200 млн ежедневно. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.08.2020, 16:51 |
|
|
start [/forum/topic.php?fid=46&fpage=51&tid=1685779]: |
0ms |
get settings: |
13ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
87ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
others: | 250ms |
total: | 453ms |
0 / 0 |