BACKUP komutu için BUFFERCOUNT, BLOCKSIZE ve MAXTRANSFERSIZE ayarı

Ben arıyorum pratik değerlerini ayarlamak için rehberlik BUFFERCOUNT, BLOCKSIZEve, MAXTRANSFERSIZEbir BACKUPkomuta. Biraz araştırma yaptım (aşağıya bakınız), biraz test yaptım ve gerçekten değerli herhangi bir cevabın "Eh, buna bağlı ..." ile başlayacağının farkındayım. Yaptığım sınama ve bulduğum kaynakların herhangi birinde gösterilen sınama (aşağıya bakınız) ile ilgili endişelerim, sınamanın büyük olasılıkla başka yükü olmayan bir sistemde yapılan bir vakumda yapılmasıdır.

Uzun süreli deneyime dayanan bu üç seçenekle ilgili doğru rehberlik / en iyi uygulamalar hakkında merak ediyorum: haftalar veya aylar boyunca birçok veri noktası. Ve spesifik değerler aramıyorum, çünkü bu çoğunlukla mevcut donanımın bir işlevidir, ancak şunu bilmek isterim:

• Çeşitli donanım / yük faktörlerinin yapılması gerekenleri nasıl etkilediği.
• Bu değerlerin hiçbirinin geçersiz kılınmaması gereken durumlar var mı?
• Hemen anlaşılmayan bunlardan herhangi birini geçersiz kılmanın tuzakları var mı? Çok fazla bellek ve / veya disk G / Ç kullanmak? Karmaşık geri yükleme işlemleri?
• Çalışan birden fazla SQL Server Örneğine sahip bir sunucum varsa (Varsayılan Örneğe ve iki Adlandırılmış Örneğe) ve aynı anda tüm 3 Örneğin yedeklemelerini aynı anda çalıştırırsam, bu kollektifin ( BUFFERCOUNT* MAXTRANSFERSIZE) mevcut RAM'i geçmiyor mu? Muhtemel I / O çekişmesi?
• Üç Sunucunun bir sunucuda olması ve aynı anda üçünün hepsinde yedeklerin tekrar çalıştırılmasıyla aynı senaryoda, her Örnek içinde aynı anda birden çok Veritabanının yedeklerinin çalıştırılması da bu değerlerin ayarını nasıl etkiler? Yani, üç Örnekten her birinin her biri 100 Veritabanına sahipse, eşzamanlı olarak çalışan 6 ila 9 yedek olacak şekilde her Örnekte 2 veya 3 yedek çalıştırma. (Bu durumda, birkaç büyük olandan ziyade birçok küçük ila orta ölçekli veritabanlarım var.)

Şimdiye kadar topladıklarım:

• BLOCKSIZE:

  • Desteklenen boyutlar 512, 1024, 2048, 4096, 8192, 16384, 32768 ve 65536 (64 KB) bayttır. ^[1]
  • Teyp aygıtları için varsayılan değer 65536 ve aksi takdirde 512'dir ^[1].
  • Bir CD-ROM'a kopyalamayı ve geri yüklemeyi planladığınız bir yedeği alıyorsanız, BLOCKSIZE = 2048 ^[1] belirtin
  • Tekli disklere yazdığınızda, varsayılan 512 iyidir; RAID dizileri veya SAN kullanıyorsanız, varsayılan ayarın veya 65536'nın daha iyi olup olmadığını görmek için test etmeniz gerekir. ^{[13 (sayfa 18)]}

  • Manuel olarak ayarlanıyorsa, değerin> = olması gerekir, veri dosyalarını oluşturmak için kullanılan Blok Boyutu ise, aşağıdaki hatayı alırsınız:

    Msj 3272, Seviye 16, Durum 0, Satır 3
    'C: \ Program Files \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ Backup \ BackupTest.bak' aygıtı 4096 donanım sektörüne sahip, ancak blok boyutu parametresi belirtiyor uyumsuz bir geçersiz kılma değeri 512. Uyumlu bir blok boyutu kullanarak ifadeyi yeniden yayınlayın.

• BUFFERCOUNT:

  • Varsayılan ^{[2], [8]} :

    SQL Server 2005 ve sonraki sürümleri:
    (NumberofBackupDevices * [mystery_multiplier]) + NumberofBackupDevices + (2 * NumberofVolumesInvolved)

  • [mystery_multiplier]: Bu değerle ilgili bazı tutarsızlıklar var. 3 şekilde ifade edildiğini gördüm:

    • 3 ^[2]
    • GetSuggestedIoDepth ^{: [8]}
    • GetSuggestedIoDepth + 1 ^{: [8]}

    
    Çarpanı gösteren test 3SQL Server 2005 SP2'de yapıldı ^[9] .

    SQL Server 2008 R2 ve 2012'deki testlerim ve SQL Server 2014 ^{[8] ile} ilgili kullanıcı yorumu , çarpanı gösteriyor 4. Yani, GetSuggestedIoDepth(doğrudan aşağıda) için rapor edilen değer verilen , ya:

    • GetSuggestedIoDepthşimdi 4, ya
    • çarpan şimdi GetSuggestedIoDepth + 1
  • GetSuggestedIoDepth3DISK cihazları için geri dönüyor ^[9]
  • Sabit bir maksimum değer yok, ancak bu belleğe ihtiyaç duyulduğunda = ( BUFFERCOUNT* MAXTRANSFERSIZE), pratik bir maksimum değer şöyle olurdu: BUFFERCOUNT <= (available_memory / MAXTRANSFERSIZE)
• MAXTRANSFERSIZE:
  • Olası değerler 65594 baytın (64 KB) 4194304 bayta (4 MB) kadar olan katlarıdır. ^[1]
  • Varsayılan değerler: Aygıt okuma modundaysa (geri yükle) veya bu Desktop veya Express Edition ise 64K kullanıyorsa, 1 MB kullanın. ^[9]
• Genel / Çeşitli:
  • Kullanılabilecek maksimum boyut ( Tampon Havuzun Fiziksel Belleğine / 16 ). GlobalMemoryStatusEx (ullTotalPhys) API çağrısından döndürüldüğü gibi . ^[9]
  • İzleme Bayrağı, 3213yedekleme / geri yükleme işlemleri gerçekleştirirken yedekleme / geri yükleme yapılandırma parametrelerini çıkarır ve 3605çıktıyı ERRORLOG dosyasına aktarır :DBCC TRACEON (3213, 3605, -1);
  • Sen kullanabilirsiniz DISK = N'NUL:'(DOS / Windows eşdeğer /dev/nullbazı ölçütlerinin daha kolay test için UNIX içinde) (fakat yazma atlama beri toplam işlem zamanının iyi bir anlamda almazsınız G / Ç)

kaynaklar

1. T-SQL YEDEK komutu için MSDN sayfası
2. KB904804: Veritabanını SQL Server 2000'de yedeklerken yavaş performansla karşılaşıyorsunuz
3. SQL Server Yedekleme Performansını Artırma Seçenekleri
4. Yedekleme ve geri yükleme
5. SQL Server Yedekleme ve Geri Yükleme'yi Optimize Etme
6. Yedekleme Performansını Optimize Etme
7. Sıkıştırma ve Katı Hal Diskleri kullanarak SQL Veritabanı Tam Yedekleme hızı nasıl artırılır
8. Yanlış BufferCount veri aktarma seçeneği OOM durumuna neden olabilir
9. Nasıl Çalışır: SQL Server Yedekleme ve Geri Yükleme aktarma boyutlarını nasıl seçer?
10. Nasıl Çalışır: SQL Server Yedekleme Tampon Değişimi (VDI Focus)
11. SQL Yedekleme büyük veritabanlarını ayarlama
12. Yedekleme Tamponu için SQL Server Belleği
13. Bir Vaka Çalışması: Bir VLDB'nin Ağ Üzerinden Hızlı ve Güvenilir Yedeklemesi ve Geri Yüklenmesi (.docx dosyası)
14. Yedekleme performansını iyileştirmek için kaç tane yedekleme cihazı önerilir?

Şunlarla test ettim:

--DBCC TRACEON (3213, 3605, -1);

BACKUP DATABASE [Test] TO
      DISK =  'NUL:'
     --,DISK = 'NUL:'
     -- DISK =  'BackupTest1.bak'
     -- ,DISK =  'BackupTest2.bak'
WITH
    STATS = 5,
    FORMAT,
    CHECKSUM,
    NO_COMPRESSION,
    COPY_ONLY
    --,BUFFERCOUNT = 40
    --,MAXTRANSFERSIZE = 4194304--2097152,
    --,BLOCKSIZE = 16384 

--DBCC TRACEOFF (3213, 3605, -1);

GÜNCELLEŞTİRME

Bazen bir soruya cevap verirken her zaman başkalarından vermelerini istediğim bilgilerin bir kısmını eklemeyi unutmuşum gibi görünüyor ;-). Mevcut durumumla ilgili olarak yukarıda bazı bilgiler verdim, ancak daha fazla ayrıntı sağlayabilirim:

24/7 / 365.25 SaaS uygulaması sağlayan bir müşteri için çalışıyorum. Bu nedenle, kullanıcıların herhangi bir noktada olma potansiyeli vardır, ancak gerçekçi olarak, kullanıcıların tümü ABD merkezlidir (şimdilik) ve çoğunlukla "standart" saatlerde çalışma eğilimindedir: 07:00 Pasifik (10:00 Doğu) - 19:00 Pasifik (yani 10 PM Doğu), ancak haftada 7 gün, hafta içi yük biraz daha hafif olsa da, sadece Pazartesi - Cuma günleri değil.

Her müşterinin kendi DB'sine sahip olacak şekilde ayarlanmışlardır. Bu bir niş endüstrisidir, bu nedenle on binlerce (veya daha fazla) potansiyel müşteri yoktur. İstemci DB'lerinin sayısı Örnek başına göre değişir, en büyük Örnek 206 müşteriye sahiptir. En büyük DB yaklaşık. 8 GB, ancak yalnızca 30 DB 1 GB'ın üzerinde. Dolayısıyla, bir VLDB'nin performansını en üst düzeye çıkarmak için çalışmıyorum.

Bu müşteriyle başladığımda, yedekleri her zaman TAM, günde bir kez ve LOG yedekleri yoktu. Ayrıca MAXTRANSFERSIZE'i 4 MB'a, BUFFERCOUNT'a 50'ye ayarlamışlardı. O kurulumu yerini biraz özelleştirilmiş bir versiyona Ola Hallengren'in veritabanı yedekleme betiğiyle değiştirdim . Hafifçe özelleştirilen kısım, her bir Örneğe bağlanırken DB'leri dinamik olarak keşfeden ve her Örnekte bağlanan boğulma işlemine izin veren (bu nedenle şu anda çalıştırıyorum. Aynı anda üç Örnek, ancak eşzamanlı olarak çalıştırma sonuçlarından emin olamadığım için her bir örnek için DB sıralı olarak).

Kurulum şimdi haftada bir gün TAM yedekleme yapmak ve diğer günlerde DIFF yedekleme yapmaktır; LOG yedekleri her 10 dakikada bir alınır. Burada soruyorum 3 seçenek için varsayılan değerleri kullanıyorum. Anlamına gelmez eski sistemde bazı büyük kusurları vardı Bir optimizasyonu geri almayı olmadığını (sırf Ama onlar olmuştu nasıl set bilerek, ben emin olmak istedim her şeyiyanlıştı). Şu anda, 206 veritabanları için, FULL yedeklemeleri (haftada bir kez) yaklaşık 62 dakika ve kalan günlerde DIFF yedeklemeleri için 7 ila 20 dakika (FULL'dan sonraki ilk gün 7, önceki günden 20 gün) sonraki TAM). Ve bu onları sırayla çalıştırıyor (tek iş parçacığı). LOG yedekleme işlemi, toplamda (tüm 3 Örnekteki tüm DB'ler), her seferinde 50 ila 90 saniye sürer (yine, her 10 dakikada bir).

DB başına birden fazla dosya çalıştırabileceğimin farkındayım, ancak a) DB'lerin çok okuyuculu ve küçük - orta boyutlarında ne kadar daha iyi verileceğinden emin değilim ve b) Geri yükleme işlemini zorlaştırmak istemiyorum ( Tek bir dosyayla uğraşmanın tercih edilmesinin çeşitli nedenleri vardır).

Ayrıca, sıkıştırmayı etkinleştirebileceğimin de farkındayım (test sorgumun kasıtlı olarak devre dışı bıraktığını) ve bunu ekibe tavsiye ettim, ancak yerleşik sıkıştırma işleminin biraz berbat olduğu dikkatimi çekti. Eski sürecin bir kısmı her dosyayı bir RAR'a sıkıştırmaktı ve kendi testlerimi yaptım ve evet, RAR sürümünün yerel olarak sıkıştırılmış sürümden en az % 50 daha küçük olduğunu gördüm . Önce dosyaları sıkıştırmak için daha sonra yerel sıkıştırmayı kullanmaya çalıştım, sonra dosyaları RAR'la çalıştım, ancak bu dosyalar, yalnızca doğal olarak sıkıştırılanlardan daha küçükken, yalnızca RAR sıkıştırılmış sürümünden biraz daha büyüktü ve haklı göstermek için yeterli bir farkla yerel sıkıştırma kullanmıyor. Yedekleri sıkıştırma işlemi asenkrondir ve her X dakikada bir çalışır. Bir bulursa .bakveya.trndosyayı sıkıştırır. Bu şekilde, yedekleme işlemi her bir dosyayı sıkıştırmak için geçen sürede yavaşlamaz.

Sorunuzda bir gemi dolusu öğeye değindiniz. Bu kadar titiz olduğun için teşekkürler!

Elden farkettiğim birkaç şey:

• Çeşitli donanım / yük faktörlerinin yapılması gerekenleri nasıl etkilediği.

24x7 örneği mi çalıştırıyorsunuz? 24 saatteki yük nedir? Yedek sıkıştırmanın devre dışı bırakıldığını fark ettim; Bu, test için tasarım gereği mi, yoksa bunu üretime sokarken kapatmanızın bir nedeni için mi isteniyor? Tonlarca donanım boşluğunuz (CPU / RAM) varsa ve yedeklemeyi en kısa sürede tamamlamanız çok önemliyse, bu parametreleri aklınızda bulundurduğunuz belirli donanım için bu parametreleri ayarlamak istersiniz. OLTP iş yüklerine günün her saatinde servis yapıldığından emin olmak ve bunun yedeğini etkilemek istemiyorsanız, büyük olasılıkla bu parametreleri ayarlamanız gerekir. Genel olarak rehberlik istediğiniz için tasarım hedeflerinizi henüz belirlemediniz, ancak akıllıca "o bağlıdır" diyor.

• Bu değerlerin hiçbirinin geçersiz kılınmaması gereken durumlar var mı?

Örneği sürdürmeden sonra yolun aşağısındaki desteklenmeyle ilgili endişeleriniz varsa ve yerine koyma becerileriniz konusunda kararsızsanız, varsayılan ayarları korumak istersiniz. Özel olarak ayarlama gereksiniminiz yoksa, varsayılan ayarları yerinde bırakmak isteyebilirsiniz. Söyledikleri gibi uyuyan köpekler yalan söylesin.

• Hemen anlaşılmayan bunlardan herhangi birini geçersiz kılmanın tuzakları var mı? Çok fazla bellek ve / veya disk G / Ç kullanmak? Karmaşık geri yükleme işlemleri?

Başvurduğunuz belgelerde açıkça belirtildiği gibi, bu parametrelerin çok fazla yükseltilmesinin çalışma süresi üzerinde kesinlikle olumsuz etkileri olabilir. Üretime dayalı her şeyde olduğu gibi, dağıtmadan önce bunu iyice test etmeniz ve ayarları kesinlikle gerekmedikçe yalnız bırakmanız gerekir.

• Birden fazla SQL Server örneği çalıştıran bir sunucum varsa (Varsayılan Örnek ve iki Adlandırılmış Örnek) ve aynı anda tüm 3 Örneği'nin yedeklemelerini aynı anda çalıştırıyorsam, kolektifin (BUFFERCOUNT) olduğundan emin olmanın ötesinde bu değerleri nasıl ayarladığımı etkiler mi? * MAXTRANSFERSIZE) kullanılabilir RAM'i geçmiyor mu? Muhtemel I / O çekişmesi?

Öngörülemeyen durumlar için bol miktarda RAM bıraktığınızdan emin olmak istersiniz. Yedekleme işlemleri için % 100 veya% 70'ten fazla kullanılabilir koç kullanma konusunda endişeliyim, aksi takdirde yedekleme penceresi sırasında hiçbir şey olamayacağını% 100 kesin olarak bilemezdim.

SQLServerScience.com'da yedekleme performansı testini nasıl yaptığımı gösteren bir kod içeren bir blog yazısı yazdım.

^{bu yazdığım en iyi cevap olmayabilir, ancak The Great One ™ 'in bir keresinde dediği gibi, "almadığınız çekimlerin% 100'ünü özlüyorsunuz"}