Toplu Ekleme süresinde büyük değişiklik

Bu yüzden, hazırlama tablomuzdan veri almak ve datamart'ımıza taşımak için basit bir Toplu Ekle işlemim var.

İşlem, "Toplu iş başına satır" için varsayılan ayarları olan basit bir veri akışı görevidir ve seçenekler "tablock" ve "kontrol kısıtlaması yok" şeklindedir.

Tablo oldukça büyük. 201 GB ve 49 GB dizin alanı ile 587.162.986 veri boyutu. Tablo için kümelenmiş dizin.

CREATE CLUSTERED INDEX ImageData ON dbo.ImageData
(
    DOC_ID ASC,
    ACCT_NUM ASC,
    MasterID ASC
)

Ve Birincil Anahtar:

ALTER TABLE dbo.ImageData 
ADD CONSTRAINT ImageData 
PRIMARY KEY NONCLUSTERED 
(
    ImageID ASC,
    DT_CRTE_DOC ASC
)

Şimdi BULK INSERTSSIS üzerinden inanılmaz yavaş çalışan bir sorun yaşıyoruz . Bir milyon satır eklemek için 1 saat. Tabloyu dolduran sorgu zaten sıralanır ve doldurulması gereken sorgunun çalışması bir dakikadan az sürer.

İşlem çalışırken, 5 ila 20 saniye arasında herhangi bir yere götüren ve bir bekleme türü gösteren BULK insertinde bekleyen sorguyu görebiliyorum PAGEIOLATCH_EX. İşlem INSERTbir seferde sadece bin sıraya kadar çıkabilir.

Dün bu süreci UAT ortamım karşısında test ederken aynı sorunla karşılaşıyordum. Süreci birkaç kez çalıştırıyordum ve bu yavaş eklemenin kök nedeninin ne olduğunu belirlemeye çalışıyordum. Sonra aniden 5 dakikadan kısa sürede koşmaya başladı. Bu yüzden aynı sonuçla birkaç kez daha çalıştırdım. Ayrıca 5 saniye veya daha uzun süre beklemede olan toplu kesici uçların sayısı yüzlerce ila yaklaşık 4 arasındadır.

Şimdi bu şaşırtıcı, çünkü aktivitede büyük bir düşüş yaşadığımız gibi değil.

Süre boyunca CPU düşük.

Daha yavaş olduğu zaman diskte daha az bekleme var gibi görünüyor.

Disk gecikmesi, işlemin 5 dakikadan daha kısa bir sürede çalıştığı zaman dilimi boyunca artar.

Ve bu sürecin zayıf olduğu zamanlarda ES çok daha düşüktü.

Zaten kontrol ettim ve dosyalar sadece% 70 dolu olduğu için dosya büyümesi olmadı. Günlük dosyasının hala% 50'si var. DB Basit Kurtarma modundadır. DB yalnızca bir dosya grubuna sahiptir ancak 4 dosyaya yayılmıştır.

Merak ettiğim şey A: neden bu toplu eklemelerde bu kadar büyük bekleme süreleri görüyordum. B: daha hızlı çalışmasını sağlayan ne tür bir büyü oldu?

Kenar notu. Bugün yine saçmalık gibi çalışıyor.

GÜNCELLEME şu anda bölümlendirilmiştir. Ancak en iyi aptalca bir yöntemle yapılır.

CREATE PARTITION SCHEME [ps_Image] AS PARTITION [pf_Image] 
TO ([FG_Image], [FG_Image], [FG_Image], [FG_Image])

CREATE PARTITION FUNCTION [pf_Image](datetime) AS 
RANGE RIGHT FOR VALUES (
      N'2011-12-01T00:00:00.000'
    , N'2013-04-01T00:00:00.000'
    , N'2013-07-01T00:00:00.000'
);

Bu, esas olarak 4. bölümdeki tüm verileri bırakır. Ancak hepsi aynı dosya grubuna gittiğinden. Veriler şu anda bu dosyalar arasında eşit olarak bölünüyor.

GÜNCELLEME 2 Bunlar, süreç zayıf çalıştığında genel bekleyişlerdir.

Bu sürecin iyi çalıştığı dönemlerde beklediğim süreç iyi çalışıyor.

Depolama altsistemi yerel olarak bağlı RAID'dir, SAN yoktur. Günlükler farklı bir sürücüde. Raid Controller, 1 GB önbellek boyutuna sahip PERC H800'dür. (UAT için) Prod bir PERC'dir (810).

Yedeklemeden basit kurtarma kullanıyoruz. Her gece bir üretim kopyasından geri yüklenir.

IsSorted property = TRUEVeriler zaten sıralandığından SSIS'yi de ayarladık .

Nedeni gösteremiyorum ama bir TOPLU INSERT işlemi için toplu iş başına varsayılan satır "all" olduğuna inanıyorum. Satırlarda bir sınır belirlemek, işlemi daha sindirilebilir hale getirebilir: bu yüzden bir seçenektir. (Burada ve devam, Transact-SQL "BULK INSERT" belgelerine bakıyorum, bu yüzden SSIS için kapalı olabilir.)

İşlemi, her biri ayrı bir işlem olarak çalışan birden çok X satırı grubuna bölme etkisi olacaktır. Bir hata varsa, tamamlanan gruplar hedef tabloya bağlı kalır ve durdurulan toplu işlem geri alınır. Yaptığınız şeyde tolere edilebilirse, yani daha sonra tekrar çalıştırabilir ve yakalayabilirsiniz, o zaman deneyin.

Tüm geçerli ekleri bir tablo bölümüne koyan bir bölümleme işlevine sahip olmak yanlış değildir, ancak aynı dosya grubundaki bölümlerle bölümlemenin ne kadar yararlı olduğunu görmüyorum. Ve datetime kullanımı zayıftır ve SQL Server 2008'den bu yana açıkça CONVERT formülü olmadan datetime ve 'YYYY-MM-DD' için bir çeşit kırık (SQL neşeyle YYYY-DD-MM olarak davranabilir: şaka yapmıyorum: panik yapma, sadece 'YYYYMMDD' olarak değiştirin, sabit: veya CONVERT (datetime, 'YYYY-AA-DDT00: 00: 00', 126), sanırım öyle). Ancak bölümleme için tarih değeri için bir vekil (int veya yıl + çeyrek olarak) kullanmanın daha iyi olacağını düşünüyorum.

Belki başka bir yerden kopyalanan veya birkaç veri standardında çoğaltılan bir tasarım. Eğer bu gerçek bir datamart ise, departman yöneticilerine oynayabilecekleri bazı veriler vermek için veri ambarından yapılan bir dökümü ise, (sizin tarafınızdan) başka bir yere gönderilmez ve muhtemelen veri kullanıcıları açısından salt okunurdur. , bana öyle geliyor ki, bölme işlevini kaldırabilirsin -veya- ne olursa olsun tüm yeni verileri dördüncü bölüme açıkça koymak için değiştirebilirsin ve kimse umursamaz. (Belki kimsenin umursamadığını kontrol etmelisin.)

Planın, bölüm 1'in içeriğini gelecekte bir süre bırakmak ve daha yeni veriler için yeni bir bölüm oluşturmak olduğu bir tasarım gibi geliyor, ancak burada olduğu gibi görünmüyor. En azından 2013'ten beri olmadı.

Ben kendim vesilesiyle büyük bölümlenmiş tablolar için ekler üzerinde aynı sporadik aşırı yavaşlık gördüm. Hedef tabloları İstatistikleri güncellemeyi ve sonra tekrar çalıştırmayı denediniz mi? Aşırı bekleme süresi zayıf istatistiklerden kaynaklanıyor olabilir ve testiniz sırasında bir noktada bir istatistik güncellemesi tetiklenmişse, bu hız artışını açıklar. Doğrulamak için sadece bir düşünce ve kolay bir test.