Остановите владельцы системы исходного кода теперь, прежде чем они имеют бедствие на их руках. Смотрите также
Эти статьи и ответы покрывают некоторые из причин этого собирается повредить базу данных.
Давайте поговорим о SSIS и задаче потока данных. Задача потока данных работает над концепцией буферов. Буфер представляет собой блок памяти размером до размера, в который будет вписываться N строк данных. Это одна из основополагающих причин, по которым SSIS настолько проницателен в отношении типов данных и всегда проверяет их. Мы можем помещать буферы 1000 @ 100 байт в память. Но тогда вы идете и удваиваете размер всех столбцов в источнике, и внезапно только 500 строк вписываются в память за один раз. Это, вероятно, замедляет общую пропускную способность.
Данные двоичного/большого объекта/данные потока различны. SSIS не знает/не может знать, будут ли эти данные вписываться в память. Вы можете уклониться от пули, и механизм выполнения сможет поместить ваши строки в буфер, и, хотя вы можете немного замедлить работу, это может быть не заметно. Но, что, если двигатель определяет это действительно - это данные LOB? Тогда ты горько. Вы можете следить за тем, чтобы ваша производительность медленно сканировалась, поскольку SSIS создает все эти прекрасные маленькие файлы в вашем BLOBTempStoragePathlocation и, возможно, BufferTempStoragePath. Вместо того, чтобы иметь данные в буфере (memory = fast), вместо этого у вас есть указатель в вашем буфере на физический путь на диске (disk = slow).
И вы получите уплату штрафных очков много за это. Думаю об этом. Вы вытаскиваете все данные из dbo.BadDecision для своего процесса ETL. Эти данные, вероятно, не все в буферном кэше, поэтому SQL Server или любая используемая вами база данных хоста должны считывать все данные с диска. Диск медленный. Возможно, вы передаете это через сеть на сервер ETL. Эти типы жира не могут вписаться в память, поэтому они записываются обратно на диск, возможно, даже не на быстрый диск, потому что вы не задали пути буфера. Предполагая, что вы не заполнили C: и вышли из строя на сервере, вы платите, чтобы записать данные, которые вы только что прочитали с диска, в отдельные маленькие файлы, в то время как данные перемещаются по конвейеру.Эта партия записей теперь готова к записи в целевые таблицы - угадайте, что? Нам нужно прочитать эти данные из этих файлов, чтобы фактически их сохранить. И, конечно же, целевая система перезаписывает эти данные на диск.
Звучит весело, не так ли?
Так что сражайся, сражайся со всем, что у тебя есть. Это плохое, ленивое решение, которое собирается укусить компанию, а не только вас и вашу команду, в значительной степени в заднице.
Непонятна точная механика разбрызгивания двигателя на диск для больших объектов. Статья Джона Уэлча уточняет: LOBs in the SSIS Dataflow
Поскольку эти типы данных имеют потенциал для хранения столько данных, SSIS обрабатывает их немного иначе, чем стандартные типы данных. Они выделяются отдельно от обычных данных в буферах. При наличии давления памяти SSIS буферизует диск на диск. Потенциальный размер данных LOB делает его очень вероятным для буферизации, что может быть довольно узким местом в производительности.
Ключевое предложение, которое я читаю, заключается в том, что SSIS не знает, будет ли этот столбец LOB или нет. В настоящее время все данные составляют менее 1000 байт, но столбец nvarchar (max). Вы говорите, что SSIS все еще может по-прежнему думать, что это большой объект. Итак, что лучший способ проверить и проверить, ошибочно ли SSIS ошибочно определяет, что это LOB. Проверьте местоположение BLOBTempStoragePath, чтобы узнать, сгенерированы ли эти файлы? – Gabe
@gabe Добавлена ссылка на статью, так как я не понял себя в деталях. Я буду копаться и посмотреть, могу ли я найти какую-либо документацию по MS. – billinkc