Избегайте метода извлечения «строка за строкой» при работе с исходными столбцами больших объектов

12

У меня есть устаревший источник базы данных PostgreSQL (ODBC), который я пытаюсь перенести на новую схему SQL Server с использованием служб SSIS. Я получаю предупреждение:

Метод извлечения 'Row by Row' применяется потому, что в таблице есть столбцы LOB. Содержимое столбца LOB

Дело в том, что ни один столбец не нужен быть большим. Есть несколько типов TEXT, но они могут легко поместиться в varchar (max). Тем не менее, даже более странно, что большинство из них уже являются varchars, но кажется, что все, что касается varchar (128), обрабатывается так, как если бы это был LOB (заранее свойства, тип данных - DT_NTEXT).

Я попытался выполнить ручную команду SQL, в которой я явно приводил каждый тип строки к varchar соответствующей длины в операторе select, и они все еще устанавливаются как DT_NTEXT в источнике ODBC.

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

Если это имеет значение, я использую SSIS-BI 2014 внутри Visual Studio 2013.

— Крис Пратт
источник

3

Когда вы явно приводили их в исходной системе к не максимальному размеру, это было в существующем потоке данных или вы создали новый или, по крайней мере, новый исходный компонент для него? Когда вы предоставляете запрос с теми же именами столбцов и только более тонкими типами, иногда это не регистрируется как изменение, поэтому редактор не запускает процесс сбора метаданных (который может быть дорогим). Кроме того, varchar (max) будет рассматриваться как большой объект для потока данных служб

— billinkc

В компоненте источника данных ODBC у вас есть возможность выбрать таблицу или использовать запрос. Вот где я делаю кастинг: в пользовательском запросе. Я упомянул в varchar(max)качестве краткого изложения то, что данные столбца могут соответствовать максимальному размеру varchar, который составляет около 4000, для целей SSIS, я думаю. Я на самом деле ничего не бросаю varchar(max); тем не менее, я использовал несколько столбцов varchar(4000), чтобы быть в безопасности.

— Крис Пратт

3

Очевидно, это сводится к тому, что SSIS рассматривает любой varchar, размер которого превышает 128, как NTEXT. Не уверен почему. Однако я могу перейти к расширенным свойствам источника ODBC и изменить типы обратно на что-то вроде DT_WSTR. Который, кажется, работает по большей части.

Однако я определил, что некоторые из таблиц, с которыми я имею дело, в некоторых из своих столбцов TEXT переносят более 4000 байтов, поэтому мне, к сожалению, приходится оставлять эти столбцы как DT_NTEXT для предотвращения усечения (SSIS не позволяет Вы устанавливаете тип DT_WSTR с более чем 4000 байтов). Полагаю, в этих случаях я просто застрял с построчным извлечением, но, по крайней мере, мне удалось исправить несколько таблиц.

— Крис Пратт
источник

3

Я использовал Преобразование данных для varchar больше 128 в качестве NTEXT, но в итоге мне удалось устранить ошибку - установить Validate External Data в False.

— CECI
источник

0

Это решение сработало для меня:

Я удалил ошибку, изменив параметр Max Varchar в свойстве источника данных. Зайдите в диспетчер соединений. Выберите опцию сборки рядом со строкой соединения. Нажмите на кнопку подключения, чтобы получить доступ к дополнительной опции. Измените значение Max Varchar.

— Карбон 4 лошадь
источник

0

В моем случае источником является ODBC Filemaker, который также обрабатывает длинный текст как тип данных LOB. Мой пакет долгое время зависал из-за чрезмерного снижения производительности для метода извлечения строк строкой, потому что в таблице есть столбцы LOB. Таким образом, будучи развернутым, он использовал тайм-аут после долгого времени и в конечном итоге терпел неудачу.

Я делюсь фактическим решением, которое сработало для меня. Один день стоимостью более 30 тыс. Фунтов данных занял у меня около 10 минут:

Уменьшите DefaultBufferMaxRows до 1 и увеличьте DefaultBufferSize до максимального значения, т.е. до 100 МБ. Затем измените исходный DSN ODBC, установив флажок «рассматривать текст как длинный varchar». И сопоставьте типы данных от источника к цели (без каких-либо изменений в расширенном редакторе исходного кода).

— Шатабди дас Чоудхури
источник