SQL Server için önerilen disk / bölüm kurulumu


14

SQL Server için diskleri / bölümleri ayarlamak için en iyi yolu ile ilgili bazı tavsiyeler arıyorum. İşte benim önemli endişelerimden bazıları:

SQL dosyaları nasıl ayrılmalıdır (veri dosyaları, günlükler, geçici)?

Çok sayıda HDD'yi RAID yapmak ve alanı bölümlemek veya her RAID için daha az disk içeren birden fazla RAID yapmak daha mı iyidir?

Veri ve günlük dosyaları farklı bir RAID türünde olmalı mı?

Varsayılan veritabanları (master, msdb, vb.) C: 'de mi bulunmalı yoksa diğer veri / günlük dosyalarıyla aynı yerde mi olmalı?

Yanıtlar:


14

İşte güzel bir blog yazısı: http://sqlserveradvisor.blogspot.com/2009/03/sql-server-disk-configuration.html

Disk hizalama ile ilgili teknik inceleme: http://msdn.microsoft.com/en-us/library/dd758814.aspx

Kısacası işletim sisteminiz RAID 1'de, veri dosyalarınız RAID 10 (tercihen) ve günlük dosyalarınız RAID 1'de olmalıdır.

SQL Performans makalesi: http://www.sql-server-performance.com/faq/raid_1_raid_5_p1.aspx

En iyi 10 performans ipucunda PDF: http://www.stlssug.org/docs/Best_Practices_for_Performance.pdf

Ayrıca performans nedenlerinden dolayı TEMPDB'nizi ayrı bir diske yerleştirmeyi unutmayın. Eminim Paul Randal buraya gelecek ve nedenini birazdan aktaracak.

MS, tempdb için neden olduğunu söylüyor: http://msdn.microsoft.com/en-us/library/ms175527.aspx


@SQLChicken: - SATA ve SAS sürücü türü tercih edilirse, bir öneri var mı? SATA üzerinden SAS? (RAID türü, vs.'den bağımsız).
Pure.Krome

1
Paranız varsa SAS sürücüler, hız ve güvenilirlik nedeniyle SATA'ya göre tercih edilir.
SQLChicken

11

Bu büyük bir 'duruma bağlı' sorusu.

Bir depolama uzmanı olmadığım için size tek tek RAID dizileri sorusunu nasıl oluşturacağınıza cevap veremiyorum, ancak geri kalanında size yardımcı olabilirim.

Dikkate almanız gereken ilk şey, çeşitli veritabanlarındaki iş yükünün ne olduğudur - OLTP (okuma / yazma) veya DSS / DW (çoğunlukla okuma). Okuma / yazma iş yükleri için artıklık ve mükemmel okuma / yazma performansı sağladığı için RAID 1 veya RAID 10'a (RAID 1 + 0) bakmalısınız. Çoğunlukla okuma iş yükleri için RAID 5 kullanabilirsiniz. RAID 5'in okuma / yazma iş yükleri için kullanılmaması nedeni, yazma işlemlerinde performans cezası ödemenizdir.

İşlem günlükleri, doğası gereği, okuma / yazma işlemidir (veya çoğunlukla yazma işlemlerini herhangi bir şey için kullanmanıza bağlı olarak değişir - örneğin günlük yedekleri veya çoğaltma) ve bu nedenle hiçbir zaman RAID 5'e konulmamalıdır.

Bu, bazı veritabanları ve iş yükleri için RAID 5 üzerinde veri dosyalarına ve RAID 1/10 üzerinde günlük dosyalarına sahip olabileceğiniz ve diğer veritabanları için RAID 1/10 üzerinde her şeye sahip olabileceğiniz anlamına gelir. Dahası, bölümlenmiş bir veritabanınız varsa, muhtemelen aynı tablo içinde bile bazı okuma-okuma ve bazı okuma / yazma verileri içerebilir. Bu, ayrı dosya gruplarına ayrılabilir ve daha sonra her dosya grubu uygun bir RAID düzeyine yerleştirilebilir.

Gerçek veritabanlarının ayrılması yine işyüküne ve temel IO alt sisteminin yeteneklerine bağlıdır; örneğin, bir RAID dizisinde bir şeyleri SAN'a göre depolamak için daha yüksek derecede ayırma gerekebilir.

Tempdb, genellikle çok yüklü bir veritabanı olduğundan ve diğer veritabanlarından ayrı olarak saklanması gerektiğinden, tek başına özel bir durumdur. Sistem veritabanları çok fazla kullanılmamalıdır ve fazlalık olduğu sürece herhangi bir yere yerleştirilebilir.

İşte size yardımcı olması gereken yazılıma yardımcı bir yazı: Fiziksel Veritabanı Depolama Tasarımı . Ayrıca G / Ç alt sisteminizin beklenen iş yükünü kaldırabildiğinden emin olun - şu teknik incelemeye bakın: Ön Dağıtım G / Ç En İyi Uygulamaları . Son olarak, doğru RAID şerit boyutunu (genellikle daha yeni sistemlerde 64K veya daha yüksek), doğru NTFS ayırma birimi boyutunu (genellikle 64K) kullandığınızdan ve Windows Server 2008 öncesi sistemlerde disk bölümü ofsetini doğru ayarladığınızdan emin olun . Bunlar hakkında bilgi ve bunlarla ilgili daha fazla bilgi ve bunları neden bu şekilde yapılandırmanız gerektiğine dair bilgi için şu blog gönderisine bakın: Disk bölüm uzaklıkları, RAID şerit boyutları ve NTFS ayırma birimleri doğru ayarlanmış mı? .

Bototm serisi: iş yükünüzü ve IO alt sistem yeteneklerinizi öğrenin ve ardından buna göre uygulayın.

Umarım bu sana yardımcı olur.

PS tempdb söz konusu olduğunda, onu nasıl yapılandırmanız gerektiğine dair büyük bir solucan kutusu ve her türlü çelişkili bilgi var. TF 1118 etrafında Misconceptions'da tempdb veri dosyası yapılandırması hakkında kapsamlı bir blog yazısı yazdım .


Büyük mesaj Paul :)
Pure.Krome

1

Kurduğum sunucular için kısa cevap her zaman

Ayrı fiziksel disklerde oturum açar, baskın 1 veya 10 (şeritleme + yansıtma)

Performans gereksinimlerine bağlı olarak kendi disklerindeki veritabanı genellikle RAID5

Baskın denetleyicileri üzerinde çok sayıda önbellek

İşletim sisteminizi ve Windows Pagefile dosyanızı ayrı bir diziye, genellikle sadece bir aynaya (Raid 1) tekrar yapıştırın. Bu, tüm yazma işlemlerini ayrı tutar, böylece ağır performans her şeyi aşağı çekmez.

Geçmişte yaşadığım şey, veritabanı yazma + günlük yazma + pagefile yazma işlemlerinin bir Raid5 dizisini aşağı çekmesi ve performansın bir el çantasında heck'e gitmesi. Sorun test, dev, vb performans iyi olacaktır. Ancak üretim ve kullanım skyrockets girdiğinizde bu sorun "mavi dışında" ve kullanıcı şikayet skyrocket görünecektir.


1

Burada benden çok daha iyi MSSQL adamları var ama genel olarak aşağıdakileri öneririm;

İşletim sistemi ve kod C: - bu yerel diskler olmalı, bir RAID1 dizi çifti olmalıdır - bunun için 2 x 2,5 inç SAS 146GB 10krpm disk kullanıyoruz, ancak 2 x SATA 7.2 disk kullanabilirsiniz. Veriler, ihtiyacınız olan boyutta oldukça hızlı (10krpm veya daha iyi) bir RAID 1/10, 5/50/6/60 dizisi üzerinde olmalıdır - bizimkileri FC SAN LUN'larda, genellikle 'katmanlı 2' / 10krpm disk grubunda tutuyoruz . Günlükler ayrı bir ÇOK HIZLI (15krpm) küçük (10GB veya daha az?) RAID 1 dizi çifti üzerinde olmalıdır - bizimkileri FC SAN LUN'larda, genellikle çok küçük bir 'tier1' / 15krpm disk grubunda veya 'tier0' / SSD grubu.

Her iki şekilde de, bunların her bir parçasını performans için ayrı iğler / diziler üzerinde istersiniz - elbette hepsi tek bir diskte çalışır, ancak sanırım performans ve maliyet dengesi arıyorsunuz.

Ana / tempdb'imizi normal veritabanlarımızla saklıyoruz, ancak ayrı bir veri dizisi LUN'a ayırabilirsiniz.

Bu yardımcı olur umarım.


Günlük sürücüleri hakkında ilginç nokta küçük olmak. Bu yazma hızına yardımcı olmak için mi? Günlük dosyası sürücülerinizin verilerinizin işleyebileceği kadar küçük olmasını denemek ve iyi bir fikir mi?
Sean Howat

Uzman olmaktan çok uzaktayım ama küçük kaldıklarını görüyoruz - kilometreniz değişebilir :)
Chopper3
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.