La comparaison de schéma SSDT ne fonctionne pas pendant une insertion en bloc

11

Je travaille sur un grand projet ETL et DW où nous utilisons le contrôle TFS / source avec SSIS et SSDT.

Aujourd'hui, j'ai découvert que pendant qu'un package SSIS effectue un BULK INSERT dans une table de base de données, il n'est pas possible d'effectuer une comparaison de schéma SSDT avec cette base de données. C'est regrettable, car certains de nos packages prennent un certain temps. Nous voulons utiliser la fonction Schema Compare pour détecter les modifications apportées à la structure de la base de données afin de les enregistrer dans notre projet SSDT pour le contrôle de version de la base de données.

En y regardant un peu plus, j'ai trouvé que la fonction de comparaison de schéma dans SSDT exécute un script SQL qui appelle la OBJECTPROPERTY()fonction système sur les tables de la base de données. Plus précisément dans mon cas, tout appel à OBJECTPROPERTY(<object_id>, N'IsEncrypted')semble être bloqué, lorsqu'il <object_id>fait référence à une table en cours d'insertion en bloc.

Dans Visual Studio, la comparaison de schéma SSDT expire simplement après un certain temps et prétend qu'aucune différence n'a été détectée.

Existe-t-il une solution à ce problème dans SSDT, ou devrais-je essayer de déposer un rapport de bogue MS Connect?

Alternativement, puisque le BULK INSERT se produit à partir d'un package SSIS, existe-t-il peut-être un moyen de faire cette insertion sans verrouiller les OBJECTPROPERTYappels sur la table? Edit: dans les destinations SSIS OLE DB, nous pouvons supprimer la coche de "Lock Table", qui fait ce qu'il dit, mais cela peut nuire aux performances dans certaines situations. Je suis beaucoup plus intéressé par une solution qui permet à la comparaison de schémas SSDT de faire son travail, même si certains objets sont verrouillés.

sql-server ssis ssdt Dan
la source
Jetez un œil à Contrôle du comportement de verrouillage pour l'importation en bloc - vous pouvez activer le «verrouillage de table sur le chargement en bloc». Vérifiez également que votre INSERT EN
stuartd
Si vous prenez des verrous de table, vous pourriez trouver la charge plus rapide si vous la désactivez quand même ( technet.microsoft.com/en-us/library/ms177445.aspx ) - quelle que soit la cause, je déclencherais une connexion car un délai d'attente devrait échouer au moins plutôt que de simplement dire qu'il n'y a pas de changement
Ed Elliott
Merci pour les réponses, stuartd et Ed Elliot. Il s'avère que nous voulons réellement verrouiller la table, pour des raisons de performances. À mon avis, SSDT devrait être en mesure de gérer cela, car nous voulons uniquement comparer la base de données, pas appliquer des modifications aux objets de la base de données. Je vais créer un message de connexion pour résoudre ce problème.
Dan
3
Les internes ne sont pas mon fort, mais si je comprends bien, vous avez un verrou sur la table. Quel que soit le verrou utilisé, l'insertion en bloc est incompatible avec le ou les verrous requis pour valider le schéma. Lecture pertinente BOL Schema lock
billinkc
Pourriez-vous peut-être mieux expliquer pourquoi la comparaison de schémas doit s'exécuter en parallèle avec une opération de chargement? Une alternative est peut-être d'avoir un modèle de référence de la base de données. Pas de données, juste un schéma. Exécutez vos comparaisons par rapport à cela, puis assurez-vous que personne ne modifie la base de données réelle où ces opérations en bloc sont effectuées sans mettre à jour le modèle de référence.
billinkc

Réponses:

19

L' OBJECTPROPERTYappel nécessite un verrou de stabilité de schéma (Sch-S), qui est uniquement incompatible avec un verrou de modification de schéma (Sch-M).

Le BULK INSERTprendra un verrou Sch-M dans certaines circonstances. Celles-ci sont répertoriées dans la section «Verrouillage et journalisation des tables lors de l'importation en bloc» des Lignes directrices pour optimiser l'importation en bloc dans la documentation en ligne:

Verrouillage d'importation en masse

Si la table de destination est en cluster, vous trouverez peut-être utile d' activer l' indicateur de trace 610 . Veuillez lire toute la série de ces articles et le Guide de performances de chargement de données et tester attentivement si vous décidez d'emprunter cette voie.

Je n'ai aucune idée pourquoi SSDT vérifie la IsEncryptedpropriété des tables. Je ne peux pas imaginer un scénario où cela a du sens, mais c'est une question pour les gens SSDT.

Paul White 9
la source
3
C'était une réponse très complète et satisfaisante. Merci beaucoup.
Dan