SQL Server 2008R2 için en uygun sürücü yapılandırması

Aşağıdaki kurulumu olan SQL Server 2008 R2 çalıştıran oldukça meşgul bir veritabanı sunucum var:

• SATA RAID 1 (2 Sürücü) - İşletim Sistemi / Programlar
• SAS RAID 10 (4 Sürücü) - SQL Veritabanı Dosyaları (veri ve günlükler)
• SAS RAID 1 (2 Sürücü) - TempDB (veri ve günlükler)

Bu sunucuya ek sürücü ekleyemediğimi varsayarsak, elimdeki yapılandırmayı en iyi şekilde kullandım mı? Yoksa burada veri dosyalarından günlüklerin izole edildiği başka bir şema düşünmeli miyim?

Güncelleme:

Daha fazla donanım bilgisi isteyenler için:

• SATA sürücüler (OS / Program bölümü için kullanılır): WD 7200 RPM 3 Gb / sn 3,5 İnç SATA
• Diğer dizilerde kullanılan SAS diskler şunlardır: Seagate 15K RPM 6 Gb / sn 3,5 inç SAS
• Kullanılan RAID denetleyicisi: LSI 9260-8i SAS / SATA 6 Gb 8 bağlantı noktası

Güncelleme 2:

Ben seçim için aşağıdaki uygun seçenekler var gibi aldığımız görüşlere dayanarak, görünüşe - Ben hangi bana söyleyebilir birine ödül ödüllendireceğinizi olasılıkla ben açıkladık bu ortamda en iyi olmak için:

1. Her şeyi olduğu gibi bırak - muhtemelen daha iyisini yapmayacağım
2. Toplam 2 diskten oluşması için 2 SAS RAID 1 sürücümü mevcut RAID 10 dizime taşıyın
3. Günlük dosyalarımı SAS RAID 1'e taşıyın ve / veya TempDB'yi (veriler veya günlükler) RAID 10'a geri yerleştirin

Bu sorunun varyantları yarı düzenli olarak gelir:

• SQL Server derlemesi
• SQL Server 2008 örneği için bir RAID düzeyi kombinasyonu seçmeme yardımcı olun
• SQL Server'daki bu diskleri BI yapılandırması için nasıl yapılandırmalıyım?

Ayrıca veri / günlük ayırma "en iyi uygulama" hakkında topuz kavgalar da vardır.

• İşlem Günlüğünü Ayrı Hacimde Yerleştirme [katı hal]?
• SQL Server - Bir SAN'da veri, günlük ve TempDB dosyalarını ayırma

Bu sunucunun ne yaptığını daha ayrıntılı analiz etmeden, daha önce verildiği gibi aynı tavsiyeler geçerlidir.

• İşletim sistemi için RAID 1
• Veri / günlükler / tempdb için RAID 10 (6 disk)

Çok az iğ bulunan bir bölmede nadiren herhangi bir nokta vardır. Daha büyük GİB kapasitesine sahip tek bir dizi, tipik olarak iş yükünüzün topaklarını ve darbelerini 2 küçük diziden daha iyi emer.

Test edilmeye değer bir varyant OS sürücüsüne tempdb koymaktır. Bunu, yalnızca yapılandırmanın adil bir şekilde karşılaştırılmasını sağlamak için tekrar tekrar yürütebileceğiniz temsili bir iş yükünüz varsa yapın. Üretimde bu düzenlemeye giderseniz, tempdb büyümesinin kısıtlandığından emin olun, böylece yanlışlıkla OS sürücüsünde tüm boş alanı tüketmeyin.

İşletim sistemi sürücülerinizin 7200RPM altlıkları olduğu göz önüne alındığında, OS sürücü yapılandırmasındaki tempdb herhangi bir fayda sağladıysa şaşırırım.

Her şey iş yükünüze bağlıdır, ancak sadece 6 sürücü ile seçeneklerinizi sınırlar. İş yükünüz, sıralama, karma tablolar ve anlık görüntü yalıtımı gibi şeyler için tempdb'ye büyük ölçüde bağımlı değilse, RAID 10'da 6 SAS sürücüsünü birlikte kullanmaktan daha iyi olabilirsiniz. Ancak, bunu kanıtlayacak metrikleri biliyorsanız veya varsa tempdb yoğun bir şekilde kullanılır, o zaman olduğu gibi ayrı tutmalısınız.

Bu, "çok meşgul" ile ne demek istediğinize bağlıdır: farklı iş yükü kalıpları (ağır ya da değil, toplu işlemler ortak ya da değil, eşzamanlı erişim düzeyi, ancak birçok değişkenin üçü), herhangi bir iğ düzenlemesinin performansı.

Günlükleri verilerden ayıran ağır bir durum için, her yazma hem günlüğü hem de veri dosyalarını güncellemeyi içerdiğinden, önemli bir fark yaratabilir, bu nedenle, her iki dosya kümesi de aynı iğ kümesinde ise, makul miktarda ekstra kafa çevirme içerir .

İş yükünüze (ve bu sürücülerin ve bunlar ile makine arasındaki herhangi bir denetleyicinin özellikleri) daha fazla başvurmadan, üç birim için gitmeye meyilli olurum: biri OS + programları ve tempdb (veri), biri ana DB için veri ve günlükler için üçüncü (hem tempdb hem de ana DB).

Tabii ki iş yükleriniz yazma işlemlerinde çok hafifse, veri ve günlükleri ayrı tutmak konusunda çok fazla zaman harcamamalısınız, çünkü performans farkı çok az olacaktır ve onlar için tüm bir birimi ayırmak oldukça israf edilebilir olacaktır. Uzay.

Asıl cevap ihtiyaçlarınıza bağlıdır, ancak genel olarak "farklı dizilere veri koy ve oturum aç", "tempdb'yi kendi dizisine koy" dan daha önemlidir.

Kullanabileceğiniz disk sayısı göz önüne alındığında, başlangıç ​​noktam:

1. İki sürücü, RAID 1 - İşletim sistemi, yürütülebilir dosyalar, sayfa dosyası.
2. Dört sürücü, RAID 5 - Tüm veri dosyaları (alternatif olarak RAID 1 + 0)
3. İki sürücü, RAID 1 - Tüm günlük dosyaları

Yapılması gereken , farklı sürücü yapılandırmalarının performansını test etmek için SQLIO'yu kullanmaktır .

DB'yi (OLTP vs depolama) için ne kullandığınıza bağlı olarak, yapılandırmanız iyi bir genel yapılandırma gibi görünür. Daha fazla diskiniz olsaydı, daha fazla seçeneğiniz olurdu.

TempDB'niz için diski RAID 0 (şerit) olarak değiştirdiyseniz daha iyi performans elde edebilirsiniz. Hata riskinizi artırır, ancak TempDB yalnızca verileri arabelleğe aldığından veri kaybı yaşayamazsınız. Bu yüzden çoğu insan bunu makul bir değiş tokuş olarak görür. Bir yedek bulundurun (veya etkin bir yedek).

Bahsetmediğiniz, ancak deneyebileceğiniz bir şey (daha önce yapmadıysanız): Microsoft, TempDB'nizi birkaç dosya (CPU başına bir tane) üzerine bölmenizi önerir. Tabii ki, ayrı disklerde olmaları en iyisidir, ancak sadece ayrı dosyalara sahip olmak yardımcı olur. http://msdn.microsoft.com/en-us/library/ms175527(v=SQL.105).aspx