Porównanie schematów SSDT nie działa, gdy trwa BULK INSERT

11

Pracuję w dużym projekcie ETL i DW, w którym używamy kontroli TFS / źródła razem z SSIS i SSDT.

Dzisiaj dowiedziałem się, że chociaż pakiet SSIS wykonuje BULK INSERT w tabeli bazy danych, nie można wykonać porównania schematu SSDT z tą bazą danych. Jest to niefortunne, ponieważ niektóre z naszych pakietów zajmują dość dużo czasu. Chcemy użyć funkcji porównywania schematów do wykrywania zmian w strukturze bazy danych w celu zapisania ich w naszym projekcie SSDT w celu kontroli wersji bazy danych.

Przyglądając się trochę temu, odkryłem, że funkcja porównywania schematów w SSDT wykonuje skrypt SQL, który wywołuje funkcję OBJECTPROPERTY()systemową na tabelach w bazie danych. W szczególności w moim przypadku wszelkie wywołania do OBJECTPROPERTY(<object_id>, N'IsEncrypted')wydają się być zablokowane, gdy <object_id>odnoszą się do tabeli, która jest obecnie wstawiana zbiorczo.

W programie Visual Studio porównanie schematów SSDT po prostu wygasa po chwili i twierdzi, że nie wykryto żadnych różnic.

Czy istnieje obejście tego problemu w SSDT, czy może powinienem spróbować zgłosić raport o błędzie MS Connect?

Alternatywnie, skoro BULK INSERT odbywa się z pakietu SSIS, to może jest jakiś sposób na wykonanie tego wstawiania bez blokowania OBJECTPROPERTYwywołań na stole? Edycja: W miejscach docelowych SSIS OLE DB możemy usunąć znacznik wyboru z „Zablokuj tabelę”, co robi, co mówi, ale w niektórych sytuacjach może to pogorszyć wydajność. Bardziej interesuje mnie rozwiązanie, które pozwala porównywać schemat SSDT, nawet jeśli niektóre obiekty są zablokowane.

sql-server ssis ssdt Dan
źródło
Spójrz na Kontrolowanie zachowania blokowania w przypadku importu luzem - możesz mieć włączoną funkcję „blokady tabeli przy ładowaniu masowym”. Sprawdź również, czy WSTAWKA
LICZBOWA
Jeśli bierzesz blokady tabeli, możesz znaleźć ładunek szybciej, jeśli mimo to go wyłączysz ( technet.microsoft.com/en-us/library/ms177445.aspx ) - bez względu na przyczynę podniosę połączenie, ponieważ limit czasu powinien co najmniej zawodzi, zamiast po prostu powiedzieć, że nie ma żadnych zmian
Ed Elliott
Dziękuję za odpowiedzi, Stuartd i Ed Elliot. Okazuje się, że tak naprawdę chcemy zablokować stół ze względu na wydajność. Moim zdaniem SSDT powinien być w stanie sobie z tym poradzić, ponieważ chcemy jedynie porównać bazę danych, a nie wprowadzać zmian w obiektach w bazie danych. Stworzę post Connect, aby rozwiązać ten problem.
Dan
3
Elementy wewnętrzne nie są moją mocną stroną, ale jak rozumiem, masz blokadę na stole. Jakakolwiek blokada zostanie podjęta, wkładka zbiorcza jest niezgodna z blokadą (blokadami) wymaganymi do sprawdzenia poprawności schematu. Odpowiednia lektura BOL Schema lock
billinkc
Czy może lepiej wyjaśnić, dlaczego porównanie schematu musi działać równolegle z operacją ładowania? Być może alternatywą jest posiadanie modelu referencyjnego bazy danych. Brak danych, tylko schemat. Uruchom porównania z tym, a następnie upewnij się, że nikt nie modyfikuje faktycznej bazy danych, w której wykonywane są te operacje zbiorcze, bez uprzedniej aktualizacji modelu referencyjnego.
billinkc

Odpowiedzi:

19

OBJECTPROPERTYPołączenia wymaga stabilność schematu (SCH-S) zamka, który jest tylko niezgodne z modyfikacją schematu (SCH-M) zamka.

W BULK INSERTniektórych okolicznościach zabierze zamek Sch-M. Są one wymienione w sekcji „Blokowanie tabel i rejestrowanie podczas masowego importu” w Wytycznych dotyczących optymalizacji masowego importu w książkach online:

Blokowanie importu zbiorczego

Jeśli tabela docelowa jest klastrowana, pomocne może być włączenie flagi śledzenia 610 . Zapoznaj się z całą serią tych postów i Przewodnikiem wydajności ładowania danych i dokładnie przetestuj, jeśli zdecydujesz się wybrać tę trasę.

Nie mam pojęcia, dlaczego SSDT sprawdza IsEncryptedwłaściwość pod kątem tabel. Nie wyobrażam sobie scenariusza, w którym ma to sens, ale jest to pytanie do ludzi z SSDT.

Paul White 9
źródło
3
To była bardzo wyczerpująca i satysfakcjonująca odpowiedź. Dziękuję Ci bardzo.
Dan