SQL Server 2005/2008 - birden çok dosya / dosya grubu - kaç tane? Neden?

Ben kalbimdeki bir geliştiriciyim - ama her zaman, bir müşterinin bu sorunlarla başa çıkmak için iyi bir DBA'sı yok, bu yüzden karar vermek için çağrıldım ....

Makul boyutta bir SQL Server veritabanı (Northwind veya AdventureWorks'ten daha büyük herhangi bir şey; kabaca 2-4GB veri artı dizinler vb.) İle ilgili olduğunda stratejileriniz / en iyi uygulamalarınız nelerdir - birden fazla dosya / dosya grubu kullanıyor musunuz?

Öyleyse: kaç tane? Ve neden?

"Her şey için bir dosya grubu" yaklaşımından ne zaman uzaklaşacağınıza karar vermeniz için ölçütleriniz nelerdir:

* database size?
* database complexity?
* availability / reliability requirements?
* what else?

Birden çok dosya grubu kullanıyorsanız, kaç dosya grubu kullanırsınız? Biri veri için, biri dizin için, biri günlük için mi? Veriler için birkaç (kaç tane)? Seçim nedenleriniz nelerdir - neden bu sayıda dosya grubunu kullanıyorsunuz :-)

Herhangi bir ipucu, işaretçi, düşünce için teşekkürler!

Şerefe, Marc

Temel kural, çekişmeyi önlemek için dosyaları farklı birimlere ayırmaktır, ancak elde ettiğiniz performans kazancı, G / Ç alt sistemi ve iş yüküne göre çılgınca değişir. Örneğin, tek bir fiziksel iş milindeki birden fazla dosya performansa kadar emilecektir, ancak birim RAID 10 dizilerinden birkaç yüz sürücüye sahip bir SAN LUN'da bulunanla aynı düzenleme iyi olabilir. Disk sırası uzunluk sayaçları, bir G / Ç darboğazınız olup olmadığını anlamanın en basit yolu olarak arkadaşınızdır.

Veritabanlarındaki G / Ç modellerine bakıyorsunuz - salt okunur, çoğunlukla oku, oku-yaz, çoğunlukla yaz, salt yaz - ve buna dayalı şeyler. Ayrıca doğru RAID seviyesini seçmeniz ve disk bölümü ofsetlerinin, RAID şerit boyutunun ve NTFS ayırma birimi boyutunun doğru ayarlandığından emin olmanız gerekir. Bazı insanlar kümelenmemiş dizinleri ayrı bir dosya grubuna ayırmayı sever, ancak burada performans kazançları yukarıda açıkladığım gibi değişir.

Performansın yanı sıra yönetilebilirliği ve kurtarılabilirliği de göz önünde bulundurmalısınız. 100 GB'lık bir veritabanı için tek, yekpare bir veri dosyasına sahip olmak, geri yükleme biriminizin bu dosya olduğu anlamına gelir. 4 25 GB dosya grubuna ayrılması, kısmi veritabanı kullanılabilirliğini ve parçalı geri yüklemeyi, zarar görmesi durumunda tek bir dosya grubunu geri yüklemek zorunda kalabileceğiniz anlamına gelir. Tabloları ve dizinleri birden çok dosya grubunda bölümlere ayırarak, veritabanının hangi bölümlerinin bakım işlemlerinden etkileneceğini de sınırlayabilirsiniz (örn. Dizin parçalanması kaldırma).

Tempdb tamamen özel bir durumdur ve tempdb'yi neden ve nasıl böleceğimize dair her şeyi açıklayan bir blog yazımına işaret edeceğim - orada birçok yanlış anlama var.

Burada size 'kapsamlı bir genelleme' önerisi vermeden, okumanız için bir grup teknik incelemeye ve blog yayınına işaret edeceğim:

• Teknik İnceleme: Fiziksel Veritabanı Depolama Tasarımı
• Teknik İnceleme: Ön Dağıtım G / Ç En İyi Uygulamaları
• Teknik İnceleme: SQL Server 2005'te Bölümlenmiş Tablolar ve Dizinler

• Teknik İnceleme: Kısmi Veritabanı Kullanılabilirliği

• Blog yazısı: TF 1118 hakkındaki yanlış algılar (tempdb düzeni)

• Blog gönderisi: Disk bölümü ofsetleriniz, RAID şerit boyutları ve NTFS ayırma birimleriniz doğru ayarlanmış mı? (disk bölümü teknik incelemesine bağlantı ile)

Umarım bu size yardımcı olur!

Bir veritabanını farklı dosya gruplarında bölme kararı, tablolarınızın mevcut boyutu ve gelecekteki büyümesini analiz ettikten sonra alınmalıdır. Bence milyonlarca satır içeren büyük bir veritabanınız veya tablolarınız yoksa, artılarını ve eksilerini dikkatlice düşünmelisiniz, çünkü düzelttiğinizden daha fazla performans sorunu yaratabilirsiniz.

Belirli tesisler altında ilginç olabilecek bazı senaryolar vardır:

• 2 dosya grubu: veri ve dizin
• 3 dosya grubu: salt okunur tablolar, okuma-yazma tabloları, dizin
• çoklu dosya grupları: salt okunur, okuma-yazma, dizin, anahtar tablosu 1, anahtar tablosu 2, ...

Dosya gruplarının SQL Server büyüme, kullanım ve performans gereksinimlerinize yardımcı olup olmayacağına karar vermek için ortamınızı analiz etmeniz gerekir.

Birden fazla dosya grubuna geçmek için bazı temel göstergeler ( bu makaleden ):

• Disk kuyruğu uygulama ve kullanıcı deneyimi sorunlarına neden olduğunda
  • Bu durumda, GÇ yoğun tablolarını barındıran yeni dosya gruplarıyla ek disk sürücüleri kullanmayı düşünün
• Belirli tablolar veritabanının% 10'u veya daha fazlası olduğunda
  • Bu durumda, bu özellikle büyük tabloları altta yatan ayrı disk sürücülerindeki dosya gruplarına ayırmayı düşünün
  • Tablo boyutuna bağlı olarak, tabloların geri kalanıyla orantılı olarak, tek tek tablolar için bir dosya grubu oluşturmayı düşünün
• Kümelenmemiş dizin ve veri alanı büyük tablolarda eşit olduğunda
  • Bu durumda, verileri ve kümelenmiş dizini kümelenmemiş dizinlerden ayırmayı düşünün
• Veritabanında neredeyse eşit oranda salt okunur ve okuma-yazma verisi bulunduğunda
  • Bu durumda, salt okunur verileri ayrı bir dosya grubunda okuma-yazma verileri olarak bölmeyi düşünün
• Veritabanı bakımını gerçekleştirmek için yeterli zaman olmadığında
  • Bu durumda, büyük tabloları farklı temel disklerdeki ayrı dosya gruplarına ayırmayı ve paralel bakım yapmayı düşünün
• İşletme veya uygulama önemli ölçüde değiştiğinde ve veriler çok daha yüksek bir oranda büyüyeceği zaman
  • Bu durumda, potansiyel büyümeyi anlamak için kullanıcılarla çalışmayı düşünün
• Arşivlenen veriler üretim verileriyle aynı veritabanında olduğunda
  • Bu durumda, ayrı dosya gruplarını veya bu ipucundaki bir veya daha fazla tekniği düşünün - SQL Server'da Veri Arşivleme

Dosya gruplarının veritabanınızın performansını artırabileceğini fark ederseniz, değişiklikleri üretim sunucularınıza uygulamadan önce kodu yazın ve süreci bir hazırlama ortamında test edin. Değişiklikleri uygulamadan önce bazı ölçümler hazırlayın ve bunları önce / sonra karşılaştırın. Bu işlemler çok kaynak yoğun ve zaman alıcı olabileceğinden, bu prosedürleri bir bakım döneminde uygulayın.

Unutmayın, yeni nesneler (tablolar ve dizinler) oluştururken, beklenen performansı sağlamak ve veritabanı nesnelerinin doğru dosya gruplarında olduğunu ve gerektiği gibi düzeltildiğini düzenli olarak doğrulamak için nesnelerin doğru dosya grubunda oluşturulduğundan emin olun.