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.