SSDT-схема порівняння не працює, поки працює BULK INSERT


11

Я працюю над великим проектом ETL та DW, де ми використовуємо управління TFS / джерелом разом із SSIS та SSDT.

Сьогодні я з’ясував, що хоча пакет SSIS виконує ВСТУПНУ ВСТУПУ в таблиці бази даних, неможливо виконати порівняння схеми SSDT з цією базою даних. Це прикро, оскільки для завершення деяких наших пакунків потрібно досить багато часу. Ми хочемо використовувати функцію Порівняння схеми для виявлення змін у структурі бази даних, щоб зберегти їх у нашому проекті SSDT для контролю версій бази даних.

Трохи докладніше вивчивши це, я виявив, що функція порівняння схем у SSDT виконує скрипт SQL, який викликає OBJECTPROPERTY()системну функцію на таблицях бази даних. Зокрема, у моєму випадку будь-які дзвінки, OBJECTPROPERTY(<object_id>, N'IsEncrypted')схоже, блокуються, коли <object_id>йдеться про таблицю, яка наразі вставляється масово.

У Visual Studio схема SSDT просто порівняти час від часу та стверджує, що ніяких відмінностей не виявлено.

Чи є вирішення цієї проблеми в SSDT, чи я можу спробувати подати звіт про помилку MS Connect?

Крім того, оскільки BULK INSERT відбувається з пакету SSIS, чи може бути якийсь спосіб зробити це вставлення без блокування OBJECTPROPERTYдзвінків на стіл? Редагувати: У пунктах призначення SSIS OLE DB ми можемо зняти галочку з "Блокування таблиці", яка виконує те, що йдеться, але це може зашкодити продуктивності в деяких ситуаціях. Мене набагато більше цікавить рішення, яке дозволяє схемі порівняння SSDT виконувати свою роботу, навіть якщо деякі об'єкти заблоковані.


Погляньте на контроль керування поведінкою блокування для масового імпорту - можливо, увімкнено функцію "Блокування таблиці на об'ємному навантаженні". Також перевірте, що BULK INSERT не вказує TABLOCK
stuartd

Якщо ви берете блокування таблиць, ви можете знайти завантаження швидше, якщо ви все одно відключите його ( technet.microsoft.com/en-us/library/ms177445.aspx ) - незалежно від причини, яку я б підніс підключення, оскільки час очікування повинен бути в принаймні, не, а просто сказати, що ніяких змін немає
Ед Елліотт

Дякую за відповіді, Стюард та Ед Елліот. Виявляється, ми насправді хочемо заблокувати стіл з міркувань продуктивності. На мою думку, SSDT має бути в змозі впоратися з цим, оскільки ми хочемо лише порівняти базу даних, а не застосовувати зміни до об'єктів у базі даних. Я буду створювати з'єднання, щоб вирішити це.
Dan

3
Внутрішні не є моїм форте, але, як я розумію, у вас замок на столі. Незалежно від того, що зроблено для блокування, об'ємна вставка не сумісна з блокуванням, необхідним для перевірки схеми. Відповідне читання блокування схеми BOL
billinkc

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

Відповіді:


19

OBJECTPROPERTYВиклик вимагає стабільності схеми (Sch-S) , замок, який є тільки несумісний з модифікацією схеми (Sch-M) замок.

У BULK INSERTдеяких обставинах затвор Sch-M прийме замок. Вони перераховані в розділі "Блокування та реєстрація таблиць під час групового імпорту" Посібника для оптимізації масового імпорту в книгах онлайн:

Блокування масового імпорту

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

Я поняття не маю, чому SSDT перевіряє IsEncryptedвластивості для таблиць. Я не можу уявити сценарій, де це має сенс, але це питання для людей з SSDT.


3
Це була дуже вичерпна і задовільна відповідь. Велике спасибі.
Dan
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.