Медленное копирование данных фабрики данных azure

Исходная база данных: PostgreSQL, размещенный на виртуальной машине Azure D16s_v3 Целевая база данных: выпуск SQL Server для разработчиков, размещенный на виртуальной машине Azure D4s_v3. Размер исходной базы данных составляет около 1 ТБ. Целевая база данных пуста с существующей схемой, идентичной исходной базе данных

Пропускная способность всего 1 МБ / с. Ничего не помогает. (Я выбрал максимальное значение DIU) SQL Server на данный момент не имеет ключей или индексов.

Размер партии 10000

Смотрите скриншот: enter image description here

Это может дать некоторое представление о том, где вы, возможно, захотите настроить копию данных: docs.microsoft.com/en-us/azure/data-factory/…

johnstaveley 29.01.2019 15:29
5
1
3 626
3
Перейти к ответу Данный вопрос помечен как решенный

Ответы 3

Увеличьте размер пакета до 1000000.

Если вы используете опцию TableName, тогда у вас должна быть эта таблица внутри раскрывающегося списка Dataset. Если вы распаковываете с помощью SQL-запроса, проверьте соединение с набором данных, нажмите «Изменить» и «удалить имя таблицы».

Я столкнулся с той же проблемой. Если вы выберете опцию запроса и укажете имя таблицы в наборе данных, вы запутаете фабрику данных Azure и усложняете выбор варианта выбора.

Ответ принят как подходящий

Я получил нечто подобное при использовании ADF для копирования данных из локального источника Oracle в приемник базы данных SQL Azure. Та же самая работа, выполняемая через SSIS, была примерно в 5 раз быстрее. Мы начали подозревать, что с типами данных что-то не так, потому что проблема исчезла, если мы привели все наши высокоточные столбцы Oracle NUMBER к меньшей точности или к чему-то вроде целого числа.

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

Десятичный тип среды выполнения фабрики данных Azure имеет максимальную точность 28. Если десятичное / числовое значение из источника имеет более высокую точность, ADF сначала преобразует его в строку. Производительность кода приведения строк ужасна.

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

Замечательный комментарий. Спасибо. У нас есть куча столбцов с этой конкретной проблемой. мы закончили тем, что использовали медленную версию, так как делаем это только раз в месяц, но это полезно знать.

user194076 15.04.2019 22:33

Я рад, что это помогло. Мне сказали, что команда ADF работает над обеспечением более высокой точности. Это прискорбно, потому что в SSIS уже есть DT_NUMERIC с максимальной точностью 38, что намного лучше. Это похоже на вопиющее упущение в продукте для предприятий. Так что в этом есть некоторая надежда на будущее.

Pittsburgh DBA 16.04.2019 04:20

У меня такая же проблема. Но у меня 61 столбец и большая часть длинного текста. В SQL у нас есть varchar (max). Как с этим бороться?

Rohi_Dev_1.0 23.06.2020 12:51

@ Rohi_Dev_1.0 Привет! С какой проблемой вы столкнулись? Возможно, это сам по себе новый вопрос.

Pittsburgh DBA 21.07.2020 22:33

Другие вопросы по теме