Confronto schema SSDT non funziona mentre è in corso un INSERTO BULK

Sto lavorando a un grande progetto ETL e DW in cui utilizziamo il controllo TFS / sorgente insieme a SSIS e SSDT.

Oggi ho scoperto che mentre un pacchetto SSIS sta eseguendo un INSERTO BULK in una tabella di database, non è possibile eseguire un confronto di schemi SSDT con quel database. Questo è un peccato, poiché alcuni dei nostri pacchetti impiegano molto tempo per essere completati. Vogliamo utilizzare la funzione Confronto schema per rilevare le modifiche alla struttura del database al fine di salvarle nel nostro progetto SSDT per il controllo della versione del database.

Analizzando un po 'di più, ho scoperto che la funzione Confronto schema in SSDT esegue uno script SQL che chiama la OBJECTPROPERTY()funzione di sistema sulle tabelle nel database. In particolare, nel mio caso, qualsiasi chiamata a OBJECTPROPERTY(<object_id>, N'IsEncrypted')sembra bloccata, quando si <object_id>riferisce a una tabella che viene attualmente inserita in blocco .

In Visual Studio, il confronto dello schema SSDT scade semplicemente dopo un po 'e afferma che non sono state rilevate differenze.

Esiste una soluzione alternativa a questo problema in SSDT o dovrei forse provare a presentare una segnalazione di bug di MS Connect?

In alternativa, poiché BULK INSERT si verifica da un pacchetto SSIS, esiste forse un modo per effettuare questo inserimento senza bloccare OBJECTPROPERTY-call sulla tabella? Modifica: nelle destinazioni OLE DB SSIS, possiamo rimuovere il segno di spunta da "Blocca tabella", che fa ciò che dice, ma ciò potrebbe compromettere le prestazioni in alcune situazioni. Sono molto più interessato a una soluzione che consenta allo Schema Compare SSDT di fare il suo lavoro, anche se alcuni oggetti sono bloccati.

sql-server ssis ssdt

— Dan
fonte

Dai un'occhiata a Controllo del comportamento di blocco per l'importazione in blocco : potresti avere abilitato il "blocco tabella su caricamento di massa". Controlla anche che BULK INSERT non specifichi TABLOCK

— stuartd,

Se si utilizzano i blocchi di tabella, è possibile che il carico sia più veloce se lo si disabilita comunque ( technet.microsoft.com/en-us/library/ms177445.aspx ) - qualunque sia la causa che solleverei una connessione perché un timeout dovrebbe molto meno fallisce piuttosto che dire semplicemente che non ci sono cambiamenti

— Ed Elliott,

Grazie per le risposte, stuartd e Ed Elliot. Si scopre che in realtà vogliamo bloccare il tavolo, per motivi di prestazioni. A mio avviso, SSDT dovrebbe essere in grado di gestirlo, perché vogliamo solo confrontare il database, non applicare modifiche agli oggetti nel database. Creerò un post di connessione per risolvere questo problema.

— Dan,

Gli interni non sono il mio forte ma a quanto ho capito, hai un lucchetto sul tavolo. Qualunque blocco venga eseguito per l'inserimento di massa è incompatibile con il blocco oi blocchi richiesti per convalidare lo schema. Lettura pertinente BOL Schema lock

— billinkc

Potresti forse spiegare meglio perché il confronto dello schema deve essere eseguito in parallelo con un'operazione di caricamento? Forse un'alternativa è avere un modello di riferimento del database. Nessun dato, solo schema. Esegui i tuoi confronti a tale proposito e assicurati che nessuno modifichi il database effettivo in cui vengono eseguite queste operazioni collettive senza prima aggiornare il modello di riferimento.

— billinkc,

La OBJECTPROPERTYchiamata richiede un blocco di stabilità dello schema (Sch-S), che è incompatibile solo con un blocco di modifica dello schema (Sch-M).

L' BULK INSERTavrà un blocco Sch-M in alcune circostanze. Questi sono elencati nella sezione "Blocco e registrazione della tabella durante l'importazione in blocco" delle Linee guida per l'ottimizzazione dell'importazione in blocco nella documentazione online:

Blocco di importazione in blocco

Se la tabella di destinazione è raggruppata, è possibile che sia utile abilitare il flag di traccia 610 . Leggere l'intera serie di tali post e la Guida alle prestazioni di caricamento dei dati e testare accuratamente se si decide di seguire questa strada.

Non ho idea del perché SSDT controlla la IsEncryptedproprietà per le tabelle. Non riesco a immaginare uno scenario in cui ciò abbia un senso, ma questa è una domanda per le persone SSDT.

— Paul White 9
fonte

Questa è stata una risposta molto completa e soddisfacente. Grazie mille.

— Dan,