SQL Server’da Disk Depolama İçin Best Practices

SQL Server’da Disk Depolama İçin Best practices

Disk, genellikle bilgisayar teknolojisinin en yavaş kısmıdır .

Uygun yapılandırma depolama sistemleri, SQL Server’ın optimum performansı ve çalışması için kritik öneme sahiptir.

Aşağıda, Microsoft’un SQL Server performansını, güvenilirliğini ve güvenliğini iyileştirmek için önerdiği en yaygın en iyi depolama uygulamalarından bazıları verilmiştir.

Disk Donanımı

 Son 50 yılda  Hard Disk Drives (HDD), güvenilirlik, kapasite ve hız açısından düzenli iyileştirmeler yaptı.

Solid-State Drives (SSD), HDD’lerden daha hızlıdır ve daha az enerji kullanır.

Son on yılda sunucu kullanımına uygun kapasitelerde ve fiyatlarda mevcuttu.

SSD’lerin güvenilirliğini artırmak için, önemli ölçüde daha iyi IO performansı sağlayan ve hataya önemli ölçüde daha az eğilimli olan kurumsal sınıf sürücüler kullanın.

Dosya sistemi

SQL Server, I/O işlemlerinin çoğunu 8K veya 64KB parçalar halinde gerçekleştirir ve en iyi performansı, DB dosyalarının yaşadığı depolama alanı 64KB (system cluster size) kullanılarak biçimlendirildiğinde gösterir.

Yönetici olarak komut isteminde aşağıdaki kodu kullanarak disk kümesi boyutunu kontrol edebilirsiniz. Sadece “E” Harfini Drive’ınıza değiştirin.

fsutil fsinfo ntfsinfo E:

Olaydan sonra düzeltmek kolay değildir, ancak bakım aralığını alabilirseniz, değişikliği yapmaya değer.

Bunu yapmanın basit bir yolu, yeni bir sürücü eklemek, sürücüyü doğru biçimlendirmek, SQL dosyalarını ona taşımak, eski Drive’ı silmek. Başka bir sürücüye geçin, vb.

SAN kullanıyorsanız, LUN bölümlerine göre hizalamalara da bakmalısınız. Bir sanal makine söz konusu olduğunda, bu dosya sistemi katmanını da göz önünde bulundurun.

Veri depolama

Veri (MDF), Günlük (LDF’ler) ve tempDB dosyalarını farklı fiziksel sürücülere ayırın.

Aynı donanımdaki başka bir bölümde olsa bile, “C:” işletim sistemi sürücüsünden tamamen ayrı olduğundan emin olun.

Ayrıca, aynı diski asla yedekler ve canlı veritabanları ile paylaşmayın. Disk arızalanırsa, hem Veritabanlarını hem de yedekleri kaybedersiniz.

Veri dosyaları ve geçici veri tabanları genellikle günlük dosyalarından daha fazla rasgele erişime sahiptir, ancak bu iş yüküne bağlıdır. Bu nedenle, mümkün olduğunda, yazma performansını artırmak için RAID 1+0 kullanın.

Dosya grupları ve veri dosyaları

Yeni başlayanlar için, birden çok dosya içeren birden çok dosya grubuna sahip olmak istiyorsunuz.

İdeal olarak, bu dosyaların tümü ayrı sürücülerdedir. Bu, verileri ve dizini okumayı/yazmayı daha hızlı hale getirir. Okuma/yazma işlemi artık çok iş parçacıklı olabileceğinden ve birden çok fiziksel disk “yardımcı olabilir”.

Bazı veriler eskiyse ve fazla değişmiyorsa (örneğin eski olan veriler), bu veriler ayrı bir dosya grubu konulabilir, ardından yalnızca bir kez yedeklenebilir ve ardından salt okunur olarak ayarlanabilir.

Ve şimdi yalnızca en son verileri yedeklemeniz gerekiyor. Bu da yedekleme, yedekleme boyutları, geri yükleme süreleri vb. için gereken süreyi azaltır.

Bu strateji aynı zamanda eski verileri daha yavaş/daha ucuz depolamaya yerleştirmemize olanak tanır.

Felaket durumunda, kurtarılana kadar DB’yi çevrimiçi hale getiremeyeceğiniz için PRIMARY dosya grubu içinde mümkün olan en az miktarda veriye sahip olmak istersiniz.

Bu nedenle, PRIMARY’yi olabildiğince küçük tutmak iyi bir fikirdir.

Bu şekilde, felaket sırasında, PRIMARY’i, o zamanki yılın verilerini çevrimiçi hale getirebilirsiniz ve bu noktada, veritabanınız yayındadır. Arka planda çalışırken, DB kullanılabilirliğini veya kullanıcıları bundan haberdar bile olmadan eski verileri geri yüklüyor olabiliriz .

Bu aynı zamanda DEV, QA, UAT gibi daha düşük ortamlara geri yüklemeyi daha küçük ve daha hızlı hale getirir çünkü artık tüm verileri geri yüklemeniz gerekmez.

Diğer hususlar

• Veritabanının otomatik büyüme ayarlarını ve işlem günlüğündeki (VLF’ler) dahili parçalanmayı gözden geçirin .
• SQL Server’daki belirli davranışları kontrol etmek için Anında Dosya Başlatma ve izleme bayraklarını etkinleştirmeyi düşünün.