Dizinleri farklı bir dosya grubunda ve sürücüye kaydetmenin, sürücünün dizin ve dizinin başvurduğu veriler arasında ileri ve geri gitmesi gerekmediği için veritabanındaki performansı artırdığını duydum. Bunun bir efsane olduğunu da duydum .
Kümelenmemiş dizinleri ne zaman ayrı bir dosya grubunda ve sürücüde saklamanız önerilir? Hangi sonuca varmam için hangi perfmon / profiler kanıtı bana yol açacak? Donanım kararda rol oynuyor mu (tek bir sürücüde RAID / SAN kullanılıp kullanılmadığı)?
Yanıtlar:
Bir DB sisteminin en yavaş kısmı disk sürücülerdir. Disk düzeyinde darboğazları ortadan kaldırmak performansı artıracaktır. Veriler aranırken ve bir dizin kullanıldığında, dizin önce aranır ve sonra ilgili veriler alınır. Hem dizin hem de veriler aynı disklerde ise, bazı çekişmeler olur. Oysa, veriler farklı (fiziksel) bir disk üzerindeyse, daha hızlı G / Ç olur ve böylece performansı artırır. Dikkat edilmesi gereken ana bölüm, verilerin veya dizinin ayrı fiziksel disklerde veya LUN'larda olmasıdır.
Diskleriniz olması koşuluyla sisteminizden daha iyi performans almanız gerekiyorsa böyle bir senaryo kullanırsınız. Senin perfmon sayaçları kullanabilirsiniz için Physical Disk – Avg. Disk sec/Read, Physical Disk – Avg. Disk sec/Write, Physical Disk – Disk Reads/sec, Physical Disk – Disk Writes/secönce ve değişikliklerin karşılaştırılması sonra olması.
Eşzamanlı I / O'nuzu farklı sürücüler arasında yaymanın performansı artıracağı kesinlikle doğrudur - bu bir efsane değildir. Bir mit, iki kez yapmanın performansı tekrar artıracağıdır.
Eğer varsa AYNI , daha sonra iki bölüme dizinizi yukarı bölme ve başka bir tane olan ve tabloları endeksleri koyarak bir zaman kaybıdır.
Dizinleri verilerden ayrı dosya gruplarına ayırmak = performans artışı oldukça tartışmalıdır. Performansı iyileştirme, onu destekleyen temel donanıma sahipseniz, ancak bunları farklı dosya gruplarına ayırmanın size tam bir destek vermemesi gerçeğiyle gerçekleşebilir. Ve ayrıca bu yüzden mükemmel artışı ölçmek kolay DEĞİLDİR.
Ref: http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA-Monkey.aspx
Önce soruyu sormalısınız. Bunu neden yapmanız gerekiyor?
Yukarıdaki listede # 5 ihtiyacını desteklemek için bu göreve baktım ve henüz buna rağmen hareket etmemiş olmama rağmen bana iyi bir teklif gibi görünüyor.
Bu kararın o kadar kolay OLMADIĞINI ve ne yapmaya çalıştığınızı anlamanız ve destekleyecek donanıma sahip olduğunuzdan emin olmanız gerektiğini unutmayın. İyi test etmedikçe ve mükemmel performansta önemli bir artış görmedikçe böyle değişiklikler yapmayın, aksi takdirde bu fikri bırakabilirsiniz. Sadece dizinleri ayrı dosya gruplarına ayırarak mükemmel bir artış bekliyorsanız buna değmez.
Bu ürünle ilgili kişisel deneyimimi size anlatacağım. Geçerli disk sürücüsü gereken alan için yeterli büyüklükte değilse kümelenmemiş dizinler ayrı bir dosya grubunda depolanmalıdır :-). Buna gülebilirsin .. ama olur.
Bu nedenle, bir veri sürücüsünde boş alan olmadan kalmak üzereyken acil durum düzeltmesi, kümelenmemiş tüm dizinleri, boş alan içeren bir sürücüdeki yeni bir dosya grubunda çevrimiçi olarak yeniden oluşturmak için güzel bir komut dosyası oluşturmaktı. Biri yeni depolama alanı satın almanın kolay ve hızlı olduğunu düşünür .. ama gerçekten öyle değil.
Performansla ilgili olarak, hareketten sonra olağan dışı bir şey görmedik. Ama her şeyin bir arada tutulduğu büyük bir SAN saklama kutusu :-).
Genel olarak; verileri ve dizinleri benzer şekilde performans gösteren ayrı disklere bölmek , o tabloya önemli yazma işlemleri veya bu dizini kullanan büyük okuma işlemleri için performansı artırabilir. Birden çok fiziksel diske yayılmış bölümlenmiş bir tablo gibi diğer bazı G / Ç işlemlerine benzer bir metodoloji.
Bununla birlikte, büyük ölçüde depolamaya da bağlıdır . Örneğin; güzel bir Fushion ioDrive (veya benzer bir şey) olan bir sunucunuz varsa ve ayrıca bireysel dönen diskleriniz varsa. Her şeyi ioDrive'da tutmak daha fazla yararlı olabilir (alan sınırlı değilse). Dikkate alınması gereken başka şeyler de vardır - RAID yapılandırması, ağ depolama yapılandırması.
Geçici donanıma sahip olmayan yoğun olmayan saatlerde benzer donanıma sahip bir test sunucusunda veya (yalnızca ikincil sunucu bir seçenek değilse) bazı işaretlemeler yapın. Yukarıdaki Sankar'ın DBA-Monkey bağlantısı düşünce için iyi bir besindir.