Використовуючи студію розвитку бізнесу SQL Server Business Intelligence, я створюю багато плоских файлів для потоків даних OLE DB, щоб імпортувати дані до моїх таблиць SQL Server. У розділі "Режим доступу до даних" в редакторі призначення OLE DB він за замовчуванням відповідає "таблиці або перегляду", а не "таблиці або перегляду - швидке завантаження". Яка різниця; Єдина помітна різниця, яку я можу помітити, - це те, що швидке завантаження передає дані набагато швидше.
Режим доступу до даних по потоку даних SSIS - в чому сенс 'таблиці або перегляду' проти швидкого завантаження?
Відповіді:
Режими доступу до даних компонента OLE DB - це два варіанти - швидкий і не швидкий.
Швидкий, або "таблиця, або перегляд - швидке завантаження", або "змінна назва таблиці або перегляду - швидке завантаження", означає, що дані завантажуватимуться на основі набору.
Повільно - або "таблиця, або перегляд", або "змінна назва таблиці або перегляду" призведе до того, що SSIS видасть одноразові оператори вставки в базу даних. Якщо ви завантажуєте 10, 100, можливо, навіть 10000 рядків, напевно, незначна різниця в продуктивності між двома методами. Однак у якийсь момент ви збираєтеся наситити свій екземпляр SQL Server усіма цими прискіпливими маленькими запитами. Крім того, ви збираєтесь зловживати хек з журналу транзакцій.
Чому б вам хотілося не швидких методів? Неправильні дані. Якби я надсилав 10000 рядків даних, а 9999-й рядок мав дату 2015-02-29, у вас були б 10-ти атомні вставки та коміти / відкати. Якщо я використовував метод Fast, ціла партія рядків у 10 кб або збереже, або жодна з них. І якщо ви хочете дізнатися, який рядок (-ів) помилився, найнижчий рівень деталізації у вас буде 10k рядків.
Тепер існують підходи до максимальної швидкості завантаження даних, які все ще обробляють брудні дані. Це каскадний підхід, і він виглядає приблизно так
Ідея полягає в тому, що ви знайдете потрібний розмір, щоб вставити якомога більше в один кадр, але якщо ви отримаєте погані дані, ви спробуєте відновити дані послідовно меншими партіями, щоб дістатися до поганих рядків. Тут я почав з максимумом вставити фіксації розміру (FastLoadMaxInsertCommit) з 10000. На Їй помилку диспозиції, я міняю його Redirect Rowз Fail Component.
Наступне призначення таке ж, як вище, але тут я намагаюся швидко завантажувати і зберігати його партіями по 100 рядів. Знову ж таки, протестуйте або зробіть певний прийом, щоб придумати розумні розміри. Це призведе до надсилання 100 партій із 100 рядків, оскільки ми знаємо, що десь там є принаймні один ряд, який порушив обмеження цілісності для таблиці.
Потім я додаю в суміш третій компонент, на цей раз я економлю в партіях по 1. Або ви можете просто змінити режим доступу до таблиці далеко від версії швидкого завантаження, оскільки це дасть такий же результат. Ми збережемо кожен рядок окремо, і це дасть нам змогу зробити "щось" з одним поганим рядком.
Нарешті, у мене є безпечне місце призначення. Можливо, це "та сама" таблиця, що і призначення, але всі стовпці оголошені як nvarchar(4000) NULL. Що б не закінчилося за цією таблицею, потрібно вивчити та очистити / відкинути або будь-який процес поганого вирішення даних. Інші переходять на плоский файл, але насправді, що б не мало сенсу для того, як ви хочете відслідковувати погані дані.
Швидке завантаження добре задокументовано за параметрами Швидке завантаження
Зберігайте значення ідентичності з імпортованого файлу даних або використовуйте унікальні значення, призначені SQL Server.
Збережіть нульове значення під час операції великого навантаження.
Перевірте обмеження на цільовій таблиці або перегляді під час операції масового імпорту.
Придбайте замок на рівні таблиці протягом тривалості операції великого навантаження. Вкажіть кількість рядків у партії та розмір фіксації.
Яка різниця; Єдина помітна різниця, яку я можу помітити, - це те, що швидке завантаження передає дані набагато швидше.
Під капотом table or viewбуде використовувати індивідуальну команду SQL для кожного рядка для вставки vs table or view - with fast load, використовує команду BULK INSERT.
Якщо ви бачите вище варіанти, які доступні в BULK INSERT, наприклад, number of rows in the batch= ROWS_PER_BATCHі commit size=BATCHSIZE
Ще один сценарій буде ..
Максимальний розмір вставки коміксів за замовчуванням (2147483647) зависокий. Так, наприклад, ви вставляєте 500K рядків, і через порушення PK пакет виходить з ладу. У цьому випадку вся партія не вдасться при використанні опції «Швидке завантаження». Ви також не зможете отримати опис помилки.
Тут ви можете вказати table or viewвихід помилки призначення. Таким чином, з 500K ви використовуєте Швидке завантаження як починаючи з розміру вставки 5K. Якщо 1 рядок у цій партії виходить з ладу, ви будете перенаправляти ці 5K партії для table or viewзавантаження - для цього використовується рядок за рядком, вставляйте ТІЛЬКИ 5K рядків, і ви можете також перенаправляти помилку table or viewна рівний файл .. так що якщо будь-який рядок не вдасться отримати пакет якщо 5K, ви зможете точно визначити, що спричинило збій.
Перевага вищевказаного методу полягає в тому, що якщо жоден з рядків не виходить з ладу, він використовуватиме BULK INSERT (швидке завантаження) для всієї партії.
SSIS шанувальника billinkc відповів на аналогічне питання про Stackoverflow .