Велика варіація часу масового вставки

Таким чином, у мене є простий процес масового вставки, щоб взяти дані з нашої поетапної таблиці та перемістити їх у нашу дані даних.

Процес - це проста задача потоку даних із налаштуваннями за замовчуванням для "Рядки на партію", а параметри - "табло" та "відсутність обмежень для перевірки".

Стіл досить великий. 587,162,986 з розміром даних 201 ГБ та 49 ГБ простору індексу. Кластерний індекс для таблиці -.

CREATE CLUSTERED INDEX ImageData ON dbo.ImageData
(
    DOC_ID ASC,
    ACCT_NUM ASC,
    MasterID ASC
)

І Первинний Ключ:

ALTER TABLE dbo.ImageData 
ADD CONSTRAINT ImageData 
PRIMARY KEY NONCLUSTERED 
(
    ImageID ASC,
    DT_CRTE_DOC ASC
)

Зараз у нас виникає проблема, коли BULK INSERTчерез SSIS працює надзвичайно повільно. 1 годину, щоб вставити мільйон рядків. Запит, який заповнює таблицю, вже відсортований, а на запит для заповнення потрібно зайняти менше хвилини.

Коли процес запущений, я бачу запит, який очікує на вставці BULK, яка займає від 5 до 20 секунд і показує тип очікування PAGEIOLATCH_EX. Процес здатний INSERTодночасно близько тисячі рядків.

Вчора під час тестування цього процесу на моєму середовищі UAT я зіткнувся з тією ж проблемою. Я кілька разів запускав процес і намагався визначити, в чому полягає першопричина цієї повільної вставки. Потім раптом воно почало працювати за 5 хвилин. Тож я провів її ще кілька разів, все з тим самим результатом. Також кількість об'ємних вставок, які чекали 5 секунд або більше, знизилася від сотень до приблизно 4.

Зараз це викликає здивування, адже це не так, як у нас було величезне падіння активності.

CPU протягом тривалості низький.

Часи, коли це повільніше, на диску здається, що менше очікує.

Затримка диска фактично збільшується протягом періоду часу, протягом якого процес працював за 5 хвилин.

І ІО був значно нижчим за часи, коли цей процес проходить погано.

Я вже перевірив і не було зростання файлів, оскільки файли заповнені лише на 70%. Файл журналу має ще 50%. БД знаходиться в режимі простого відновлення. У БД є лише одна група файлів, але вона поширюється на 4 файли.

Отже, що мені цікаво : чому я бачив такі великі очікування на цих об'ємних вставках. Б: яка магія трапилася, що змусила її бігти швидше?

Бічна примітка. Сьогодні вона знову біжить як лайно.

ОНОВЛЕННЯ на даний момент розділено. Однак це робиться методом, який у кращому випадку є дурним.

CREATE PARTITION SCHEME [ps_Image] AS PARTITION [pf_Image] 
TO ([FG_Image], [FG_Image], [FG_Image], [FG_Image])

CREATE PARTITION FUNCTION [pf_Image](datetime) AS 
RANGE RIGHT FOR VALUES (
      N'2011-12-01T00:00:00.000'
    , N'2013-04-01T00:00:00.000'
    , N'2013-07-01T00:00:00.000'
);

Це залишає по суті всі дані в 4-му розділі. Однак оскільки все відбувається в одній групі файлів. Наразі дані досить рівномірно розподілені між цими файлами.

ОНОВЛЕННЯ 2 Це загальні очікування, коли процес працює погано.

Це очікування в той період, коли мені вдалося запустити, процес працює добре.

Підсистема зберігання локально приєднана RAID, без участі SAN. Журнали знаходяться на іншому диску. Рейдер-контролер PERC H800 з розміром кешу в 1 Гб. (Для UAT) Prod - це PERC (810).

Ми використовуємо просте відновлення без резервних копій. Він відновлюється з виробничої копії щовечора.

Ми також встановили IsSorted property = TRUEв SSIS, оскільки дані вже відсортовані.

Я не можу вказати на причину, але я вважаю, що за замовчуванням рядків на партію для операції BULK INSERT "все". Встановлення ліміту в рядках може зробити операцію більш засвоюваною: саме тому це варіант. (Тут і продовжуюсь, я переглядаю документацію Transact-SQL "BULK INSERT", щоб це могло бути вихідним для SSIS.)

Це призведе до розбиття операції на кілька партій X рядків, кожна з яких працює як окрема транзакція. Якщо виникла помилка, завершені партії залишаться зафіксованими в таблиці призначення, а партія, яка була зупинена, відкинеться. Якщо це допустимо в тому, що ви робите, тобто ви можете повторно запустити його пізніше і наздогнати, то спробуйте це.

Неправильно функціонувати розділ, який розміщує всі поточні вставки в один розділ таблиці, але я не бачу, наскільки корисно взагалі розділити його розділами в одній групі файлів. А використання datetime є поганим, і фактично зламане для datetime та "YYYY-MM-DD" без явної формули CONVERT з часу SQL Server 2008 (SQL може з радістю трактувати це як YYYY-DD-MM: не жартуйте: не панікуйте, просто змініть його на "YYYYMMDD", фіксований: або CONVERT (дата, "YYYY-MM-DDT00: 00: 00", 126), я думаю, що це так). Але я думаю, що використання проксі для значення дати (рік як int або рік + квартал) для розділу буде працювати краще.

Можливо, це дизайн, скопійований з інших місць, або продубльований через декілька даних даних. Якщо це справжній макет даних, дамп із сховища даних, щоб дати менеджерам відділів деякі дані, з якими можна грати, які не (ви) надсилаєтесь в інше місце, і, ймовірно, лише для читання, що стосується користувачів даних , то мені здається, що ви можете видалити функцію розділу-або- змінити її, щоб явно помістити всі нові дані в четвертий розділ незалежно від того, що нікого не хвилює. (Можливо, вам слід перевірити, що нікого не хвилює.)

Це здається дизайном, де планується скинути вміст розділу 1 деякий час у майбутньому та створити ще один новий розділ для отримання нових даних, але це не здається, що це відбувається тут. Принаймні, це не сталося з 2013 року.

Я сама бачила цю спорадичну надзвичайну повільність у вставках до великих таблиць з розділами. Ви спробували оновити статистичні таблиці таблиць призначення, а потім знову запустити? Екстремальний час очікування може бути пов’язаний з поганою статистикою, і якщо оновлення статистики було запущено в якийсь момент під час тестування, то це пояснило б підвищення швидкості. Просто думка і простий тест для перевірки.