Bir BULK INSERT işlemi sürerken SSDT Şema Karşılaştırması çalışmıyor


11

Hem SSIS hem de SSDT ile birlikte TFS / kaynak kontrolünü kullandığımız büyük bir ETL ve DW projesinde çalışıyorum.

Bugün, bir SSIS paketi bir veritabanı tablosuna BULK INSERT gerçekleştirirken, bu veritabanına karşı bir SSDT Şema Karşılaştırması gerçekleştirmenin mümkün olmadığını öğrendim. Bu talihsiz bir durum, çünkü bazı paketlerimizin tamamlanması oldukça uzun sürüyor. Veritabanı yapısındaki değişiklikleri veritabanının sürüm kontrolü için SSDT projemize kaydetmek amacıyla Şema Karşılaştırma işlevini kullanmak istiyoruz.

Biraz daha bakarak, SSDT Şema Karşılaştırma işlevinin OBJECTPROPERTY()veritabanındaki tablolarda sistem işlevini çağıran bir SQL komut dosyası yürüttüğünü buldum . Özellikle benim durumumda, şu anda toplu eklenen bir tabloya atıfta varsa , herhangi bir çağrı OBJECTPROPERTY(<object_id>, N'IsEncrypted')engellenmiş gibi görünüyor <object_id>.

Visual Studio'da, SSDT Şema Karşılaştırması bir süre sonra zaman aşımına uğrar ve fark bulunmadığını iddia eder.

SSDT'de bu soruna geçici bir çözüm var mı, yoksa bir MS Connect hata raporu göndermeye çalışmalıyım?

Alternatif olarak, BULK INSERT bir SSIS paketinden oluştuğu için, bu ekleme OBJECTPROPERTYişlemini tablodaki çağrıları kilitlemeden yapmanın bir yolu var mıdır? Düzenleme: SSIS OLE DB hedefleri, "Kilit Tablosu", ne diyorsa onu onay işareti kaldırabilirsiniz, ancak bu bazı durumlarda performans zarar verebilir. Bazı nesneler kilitli olsa bile, SSDT Schema Compare'in işini yapmasına izin veren bir çözümle daha fazla ilgileniyorum.


Göz at , toplu alma için Kontrol Kilitleme Davranış - Sen 'toplu yük tablo kilidi' etkin olabilir. Ayrıca BULK INSERT
cihazınızın

Masa kilitleri alıyorsanız, yine de devre dışı bırakırsanız yükü daha hızlı bulabilirsiniz ( technet.microsoft.com/en-us/library/ms177445.aspx ) - nedeni ne olursa olsun, bağlantıda zaman aşımı olması gerekir en azından başarısız olduğunu söylemek yerine başarısız
Ed Elliott

Cevaplar için teşekkürler, stuartd ve Ed Elliot. Performans nedenleriyle aslında masayı kilitlemek istediğimiz ortaya çıkıyor. Kanımca SSDT bunun üstesinden gelebilmelidir, çünkü sadece veritabanını karşılaştırmak istiyoruz, veritabanındaki nesnelere değişiklik uygulamak istemiyoruz. Bunu ele almak için bir bağlantı yazısı oluşturacağım.
Dan

3
İç kısımlar benim forte'm değil ama anladığım kadarıyla masada bir kilit var. Alınan kilit ne olursa olsun, toplu ekleme şemayı doğrulamak için gereken kilit (ler) ile uyumlu değildir. İlgili okuma BOL Şema kilidi
billinkc

Şema karşılaştırmasının neden bir yükleme işlemine paralel çalışması gerektiğini daha iyi açıklayabilir misiniz? Belki de alternatif bir veritabanı referans modeline sahip olmaktır. Veri yok, sadece şema. Karşılaştırmalarınızı çalıştırın ve ardından bu toplu işlemlerin gerçekleştirildiği gerçek veritabanını ilk önce referans modelini güncellemeden kimsenin değiştirmediğinden emin olun.
billinkc

Yanıtlar:


19

OBJECTPROPERTYArama bir şema stabilitesi, sadece (Sch-S), kilit gerektirir uyumlu bir şema modifikasyonu (Sch-M) kilit ile.

BULK INSERTBazı durumlarda bir Sch-M kilit alacaktır. Bunlar, Çevrimiçi Kitaplarda Toplu İçe Aktarmayı Optimize Etme Yönergeleri'nin "Toplu İçe Aktarma Sırasında Tablo Kilitleme ve Günlüğe Kaydetme" bölümünde listelenmiştir :

Toplu İthalat Kilitleme

Hedef tablo kümelenmişse, 610 izleme işaretinin etkinleştirilmesine yardımcı olabilirsiniz. Lütfen bu yayınların tüm serisini ve Veri Yükleme Performans Kılavuzu'nu okuyun ve bu rotaya gitmeye karar verip vermediğinizi iyice test edin.

Neden SSDT IsEncryptedtablolar için özelliği denetler hiçbir fikrim yok . Bunun mantıklı olduğu bir senaryo hayal edemiyorum, ama bu SSDT halkı için bir soru.


3
Bu çok kapsamlı ve tatmin edici bir cevaptı. Çok teşekkür ederim.
Dan
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.