Ücretsiz danışmanlık yapmak Monitis'te eski bir gelenek haline gelmiştir. Daha önce Apache LAMP güvenliğinden, MS SQL Server verilerinin VBScript ile izlenmesi hakkında bilmek istediğiniz her şey, Powershell üzerinden Windows Log dosyalarının izlenmesine kadar her konuda öneri ve rehberlik sunan makaleler yayınlamıştık.
Bu yazımızda, Microsoft SQL Server ile olan deneyiminizi nasıl en üst düzeye çıkaracağınızı ele alacağız.
SQL Server ürünü Microsoft firmasının ilişkisel veritabanı ürünüdür. Bu ürün yüksek derecede ölçeklenebilir sürümleri olan, pazardaki lider ürünlerden biridir. Ücretsiz Express sürüm haricide Standart ve Enterprise sürümler vardır. (Daha fazla bilgi için: http://www.microsoft.com/sqlserver/en/us...mpare.aspx)
Veritabanı sunucuları yönetmek ve yapılandırmak karmaşık bir iştir. Bu makalede, SQL Server ortamınızı optimize etmek için yararlı bulabileceğiniz bir dizi ipucunu inceleyeceğiz.
İşte MS SQL Server performansını en iyi duruma getirmek için kullanabileceğiniz 30 ipucu:
Yazar: 14 Aralık 2017, Hovhannes Avoyan (https://www.monitis.com/blog/author/havoyan/)
Türkçe’ye çeviren: 4 Ekim 2019, C. Sunguray
Orijinal makale: https://www.monitis.com/blog/30-ms-sql-p...ance-tips/
Bu yazımızda, Microsoft SQL Server ile olan deneyiminizi nasıl en üst düzeye çıkaracağınızı ele alacağız.
SQL Server ürünü Microsoft firmasının ilişkisel veritabanı ürünüdür. Bu ürün yüksek derecede ölçeklenebilir sürümleri olan, pazardaki lider ürünlerden biridir. Ücretsiz Express sürüm haricide Standart ve Enterprise sürümler vardır. (Daha fazla bilgi için: http://www.microsoft.com/sqlserver/en/us...mpare.aspx)
Veritabanı sunucuları yönetmek ve yapılandırmak karmaşık bir iştir. Bu makalede, SQL Server ortamınızı optimize etmek için yararlı bulabileceğiniz bir dizi ipucunu inceleyeceğiz.
İşte MS SQL Server performansını en iyi duruma getirmek için kullanabileceğiniz 30 ipucu:
- SQL Server için kullandığınız donanımı (server-sunucu) başka işler için kullanmayın.
Diğer işleriniz SQL Server ile aynı sunucuda çalışıyorsa bellek ve diğer donanım kaynaklarınız bu işlerle paylaşılıyor demektir. Bu durum bir performans sorunu yaşadığınızda sorunun nedenini bulmanızı zorlaştıracaktır. Böyle bir durumda kendinizi kolaylıkla sorunun SQL Server’dan mı yoksa diğer işten mi kaynaklandığını ararken bulabilirsiniz.
- Birden çok disk denetleyici kullanın
SQL Server sunucusunun, verilerin birden fazla disk sürücüsünde dağıtık olarak bulunmasından yararlanabilecek özellikleri vardır. Bir depolama denetleyicisinin veri transfer verimliliğinin de bir sınırı vardır. Ayrıca, birden fazla disk kullanırken, Giriş/Çıkış (ing. Input/Output) darboğazlarını önlemek için birden fazla denetleyici kullanmak daha iyi sonuç verir.
- Uygun RAID yapılandırmasını kullanın
Bir RAID (Bağımsız Disklerin Yedekli Dizisi) düzeyini seçmek söz konusu olduğunda, maliyet, performans ve kullanılabilirlik tercihlerine göre karşımıza RAID 5 veya RAID 0 + 1 seçenekleri çıkar. RAID 5 seçeneği RAID 0 + 1'den daha ucuzdur ve RAID 5, okuma işlemleri için yazma işlemlerinden daha iyi performans gösterir. RAID 0 + 1 daha pahalıdır ve yoğun yazma işlemleri için daha iyi performans gösterir.
İmkânınız varsa, yazılım tabanlı RAID yerine donanım tabanlı RAID'leri tercih etmelisiniz. Yazılımsal RAID sistemleri genellikle daha ucuzdur. Ancak merkezi CPU’dan bir kısım performans harcar. RAID denetleyicileri ise bu iş yükünü kendi işlemcileri üzerinden halleder.
- Çok kullanılan tablolar ve indeksleri ayrı bir diskte konumlandırın
Çok yoğun kullanılan tablo ve indekslere sahipseniz performansı artırmak için bu tablo ve indeksleri farklı bir dosya grubu (ing. filegroup) ve ayrı bir fiziksel sabit diskte konumlandırabilirsiniz.
- Mevcut iş yükünüzü ve performans ölçütlerinizi takip edin
Tüm optimizasyon çalışmalarının temelinde optimize edeceğimiz kaynakların nasıl kullandığınızı bilmek vardır. Genel olarak, SQL Server çalışırken bol miktarda bellek kullanmayı sever. Ancak iş yüküne bağlı olarak işlemci ve diskleri farklı kullanım şekillerine göre ayarlayabilirsiniz. Sürekli olarak sistem kaynak kullanımları takip altında tutun ve ayarlarınızı, kaynaklarınızı en yüksek seviyede kullanılacak şekilde ayarlamaya odaklanın.
- OLAP ve OLTP iş yüklerini ayırın
Aynı sunucudaki OLAP (Online Analytical Processing - Çevrimiçi Analitik İşleme) ve OLTP (Online Transaction Processing - Çevrimiçi İşlem İşleme) iş yüklerinin birbirleriyle çakışmayacak şekilde tasarlanması gerekir. OLAP ve raporlama iş yükleri genellikle daha az sıklıkta tekrar eden ama uzun süren sorgulardır. Öte yandan, OLTP iş yükleri, kullanıcıya çok hızlı cevap veren birçok küçük işlemden oluşan sorgulardır. Uzun zaman alan, analiz, raporlar veya geçici sorgular için kullanılan OLAP sorguları, OLTP işlemlerinizin hızlı çalışmasını engelleyebilir. Sunucunuzun her iki iş yükünü de desteklemesini istiyorsanız, OLAP'ı destekleyen bir raporlama sunucusu oluşturun. Çok fazla analiz yapma ihtiyacınız varsa, bu işlemleri gerçekleştirmek için SQL Server Analiz Hizmetlerini (SQL Server Analysis Services) kullanmayı düşünün.
- Veri tabanlarını sabit boyutlu olarak ayarlayın
Veritabanını oluştururken fiziksel dosyaları uygun bir büyüklükte oluşturursanız, disk üzerinde ayrılan alanın bitişik olacağından ve bu nedenle mümkün olan en iyi performansı elde edeceğinizden emin olabilirsiniz. Bunun yerine, otomatik büyüme (ing. Autogrow) seçeneğini kullanırsanız, disk alanı yalnızca gerektiğinde tahsis edilir ve fiziksel dosyalarınız muhtemelen birçok parçadan oluşur. Parçalanmış (ing. fragmented) bir veritabanı bitişik olandan daha kötü performans gösterir. Bu nedenle, veritabanını ilk oluştururken diskte yeterli alan ayırmak daha iyidir.
- tempdb’yi ayrı bir diskte konumlandırın
Tempdb veritabanı, GROUP BY veya ORDER BY gibi işlemler yaparken kullanılan geçici bir depolama alanıdır. Tempdb'yi ayrı bir diskte tutmak, bu tür bir işlemin diğer veritabanı işlemlerinin performansını olumsuz yönde etkilemesini engeller.
- Data ve log’ları ayrı bir diskte konumlandırın
Veritabanı ve günlük (ing. log) dosyalarının kullanım şekilleri farklıdır. Veritabanı dosyası genellikle rasgele (ing. random) bir şekilde okunur ve yazılırken, günlük dosyası çoğunlukla sırayla (ing. sequential) yazılır. Bunları farklı fiziksel disklerde konumlandırmak, işlemlerimizin mümkün olan en iyi performansla yürütülmesini sağlar.
- Tablo bölümleme (ing. partitioning) kullanın
Bölümleme, aynı tablonun bölümlerini farklı fiziksel disklerde tutmanıza imkân tanır. Örneğin eski verilerinizi farklı bir veritabanında tutmak yerine güncel verilerle geçmiş verileri ayırmak için bir bölüm kullanabilir ve böylece tüm verileri aynı tabloda tutabilirsiniz. Sık başvurulan güncel verilerinizi hızlı disklerinizde konumlandırarak yüksek performans elde edebilirsiniz.
- İndeks oluşturun
İndeksler, veritabanı tablolarındaki verilerin en uygun ve hızlı şekilde aranmasını sağlar. Özellikle yüksek kayıt sahip tablolarda yüksek performans elde etmek için WHERE, ORDER BY ve GROUP BY deyimlerinde sıkça kullanılan sütunları içeren indeksler oluşturmanız gerekir.
- Kümelenmiş (ing. clustered) indeksler oluşturun
Belli bir değer aralığı döndüren veya ORDER BY ile sıralanmış sonuçlar döndüren veya GROUP BY ile gruplanmış sonuç döndüren sorguların performansını artırmak için kümelenmemiş (ing. non-clustered) yerine kümelenmiş (ing. clustered) indeksler oluşturun. Bir tablo yalnızca bir kümelenmiş indekse sahip olabileceğinden, bu indekste kullandığınız sütunları dikkatli seçmelisiniz. Tüm sorgularınızı analiz edin, en sık kullanılan sorguları seçin ve kümelenmiş indekse yalnızca en yüksek performansı sağlayan sütunları ekleyin.
- Kümelenmemiş (ing. non-clustered) indeksler oluşturun
Seçiciliği yüksek, az sayıda satır döndüren sorgularınızın performansını artırmak için kümelenmemiş indeksler oluşturun. Bir tabloda en fazla 249 kümelenmemiş indeks bulunabilir. Kümelenmemiş indeks oluştururken her indeksin disk alanı kullanacağını ve veri güncelleme işlemlerinin performansını etkileyeceğini unutmayın.
- Düzenli olarak indeksleri yeniden oluşturun (ing. rebuild)
Kayıtlarınızı güncellerken, silerken ve yeni kayıtlar girerken zaman içerisinde indeksleriniz bölümlere ayrılır (ing. fragment) ve bu da performansın düşmesine neden olur. Performansı en iyi seviyede tutmak için indeksleri düzenli aralıklarla yeniden oluşturmalısınız. Kümelenmiş (ing. clustered) bir indekse sahip tablolarda, bu indeksin yeniden oluşturulması, aynı zamanda tablo verisinin de birleştirilmesini (ing. defragmenting) sağladığı için ayrıca yararlıdır.
- Kapsayıcı indeksler kullanın
Kapsayıcı indeks bir sorguda kullanılan tüm sütunları içeren indekslerdir. Kapsayıcı indekslerin performansı artırmasının nedeni, gerekli olan verinin tamamının indeks içerisinde bulunmasıdır. Verileri elde etmek için yalnızca indeks sayfalarını okumak (veri sayfalarını değil) yeterlidir. Kapsayıcı indeksler tahmin ettiğinizden daha fazla performans artışı sağlayabilir. Çünkü G/Ç (ing. I/O) işlemlerinin sayısı dramatik şekilde düşer.
- Kullanılmayan indeksleri silin.
Yazdığınız veya kullandığınız uygulama verileri çok sık güncelliyorsa, performansı artırmak için tablolarınızdaki indeks sayısını sınırlayın. Her indeks disk alanı kullandığından ve satır ekleme, silme ve güncelleme işlemlerini yavaşlattığından, yalnızca veri kullanımını, gerçekleştirilen sorgu türlerini ve sıklıklarını ve sorgularınızın yeni indeksleri nasıl kullanacağını analiz ettikten sonra yeni indeksler oluşturmalısınız. Çoğu durumda, yeni indeks oluşturmanın sağladığı hız avantajı, bu indeksin fazladan kullandığı disk alanı ve satırların yavaş güncellenmesi dezavantajlarından ağır basar. Sorgularınızda kullanılmayan indeksleri tanımlamak için İndeks Sihirbazı'nı (ing. Index Wizard) kullanın.
- Sadece ihtiyacınız olan verileri alın
Sık sık tüm sütunlardaki bilgilere ihtiyacımız olmadığı halde veritabanından tüm sütunları getiren “SELECT * FROM…” komutunu yazmak daha kolayımıza gelir. İşlenen verinin boyutunu azaltman için sadece ihtiyacınız olan sütunların adlarını belirtmelisiniz.
- Kilitlenmeyi en aza indirmek için kilitleme (ing. locking) ve yalıtım seviyesi (ing. isolation level) ipuçlarını kullanın
İşlemlerinizde, mümkün olduğunda “WITH NOLOCK” seçeneğini kullanın. Bu sayede uygulamanızın aynı satırlara aynı anda erişmesi için uzun süre beklemekten kurtulursunuz.
- Sorgularda parametreler kullanın
SQL Server query optimizer, en son kullanılan sorgu planlarını bellekte tutar. Parametre kullanmadığınızda, her sorgunuz diğerinden farklı olacağı için query optimizer bellekte tuttuğu sorgu planlarını kullanamayacaktır. Parametre kullandığınızda ise hem bellekteki sorgu planları kullanılabilecek hem de bellekteki sorgu planı sayısı azalacaktır.
- Her sütun için en küçük veri türünü seçin
Açık (ing. explicit, CAST ve CONVERT ile yapılan) ve otomatik (ing. implicit, SQL Server’ın dönüşüme kendi karar verdiği) tip dönüşümlerinin maliyeti dönüşümün gerçekleştirilmesi için geçen süre açısından yüksek olabilir. Ayrıca optimize edici (ing. optimizer) sorguyu değerlendirmek için bir indeks kullanamadığı için ortaya çıkabilecek tablo veya indeks taramaları da sorguyu yavaşlatacaktır.
- Text veri tipi yerine varchar kullanın
Metin (ing. text) veri türüne sahip sütunlar SQL Server’a fazladan iş yükü getirir. Çünkü metin ve resim veri türleri normal veri sayfaları yerine metin / resim sayfalarında ayrı olarak depolanırlar. 8.000 karakterden az uzunluğu olan sütunlarda üstün performans için metin yerine varchar türünü kullanın.
- Unicode'u yalnızca gerekli olduğunda kullanın
Nchar ve nvarchar gibi Unicode veri türleri, char ve varchar gibi ASCII veri türlerine kıyasla iki kat daha fazla depolama alanı kaplar.
- İmleç (ing cursor) kullanımını azaltın
İmleçler, select ifadelerine göre performansın düşmesine neden olabilir. Satır satır işlemler yapmanız gerektiğinde, ilişkili alt sorguları (ing. correlated subqueries) veya türetilmiş tabloları (ing. derived tables) kullanmayı tercih edin.
- Kaynaklarınızı şema tasarımına uygun şekilde tahsis edin
Şema yapınızın kaynaklarınızın iş gereksinimlerinize göre kullandığına emin olun. Doğru veri modelini bulmak ve bu model test etmek için zaman ayırın. Tasarımınızın işinize uygun olduğundan ve tasarımın tüm nesneler arasındaki ilişkileri doğru şekilde yansıttığından emin olun. Sisteminiz canlı kullanıma geçtikten sonra bir veri modelini değiştirmek zahmetli ve zaman alıcıdır. Ayrıca kaçınılmaz olarak birçok yazılım kodu etkiler.
- Tetikleyici (ing. trigger) içinde uzun işlemlerden kaçının
Geliştiriciler sistemlerini performans ve ölçekleme konusunda değerlendirirken genelde tetikleyicileri (ing. trigger) göz ardı ederler. Tetikleyiciler her zaman INSERT, UPDATE veya DELETE işlemlerinin bir parçası olduğundan, tetikleyicide uzun süredir devam eden bir eylem kilitlerin beklenenden daha uzun sürmesine neden olur ve bu da diğer sorguların engellenmesine neden olabilir. Tetikleyici kodunuzu mümkün olduğunca küçük ve verimli tutun. Uzun süren veya kaynak yoğun bir işlem yapmanız gerekiyorsa, görevi eşzamansız (ing. asynchronous) olarak gerçekleştirmek için mesaj sıralamasını (ing. message queuing) kullanın.
- “NOT LIKE” gibi yüksek kaynak tüketen operatörleri kullanmaktan kaçının
Birleşme veya tahminlerde kullanılan bazı operatörler, kaynakların aşırı kullanılmasına sebep olur. Joker karakterler içine alınmış bir değeri olan LIKE operatörü (yani '%değer%') neredeyse her zaman bir tablonun tamamının taranmasına neden olur. Bu tür tablo taraması, önceki joker karakter nedeniyle çok maliyetli bir işlemdir. Sadece kapanış joker karakteri içeren “LIKE” operatörleri, bir B+ ağacının (ng. B plus tree) bir parçası olduğu için bir indeks kullanabilir. Ve indeks, metin değeri soldan sağa eşleştirilerek kullanılır. <> (farklı) veya NOT LIKE gibi olumsuz işlemlerin de etkin bir şekilde işlenmesi çok zordur. Mümkünse bu sorgularınızı, başka bir şekilde yeniden yazmaya çalışın. Bir kaydın sadece varlığını kontrol ediyorsanız, NOT LIKE ve <> yerine “IF EXISTS” veya “IF NOT EXISTS” yapısını kullanın. Böylece hem bir indeks kullanılmasını hem de kayıt taramasının bulunan ilk kayıtta durmasını sağlayabilirsiniz.
- Sorgu yürütme planlarını (ing. query execution plan) gözden geçirin
SQL Query Analyzer'da, Yürütme Planını Görüntüle seçeneğini etkinleştirin. Sorgunuzu, optimizer tarafından oluşturulan planı anlamlı şekilde değerlendirebilmeye yetecek bir veri yüküyle çalıştırın. Bu planı değerlendirin ve ardından optimize edicinin (ing. optimizer) kullanabileceği tüm iyi indeksleri belirleyin. Ayrıca, sorgunuzun çalışması en uzun süren ve optimize edilmesi gereken bölümlerini tespit edin. Mevcut sorgunun planını anlamak, bu sorguyu optimize etmeye yönelik ilk adımdır. İndeksleme işleminde olduğu gibi, en uygun planın ne olduğunu tespit edebilmek zaman alıcı, tecrübe ve bilgi gerektiren bir işlemdir.
- Dinamik kod için Sp_executesql kullanın
Uygulamanızda dinamik kod kullanmanız gerekiyorsa, sp_executesql sistem yordamını kullanarak çalıştırın. Bu, T-SQL'de parametreli sorgular (ing. parametrized queries) yazabilmenizi ve yazdığınız kod için yürütme planını (ing. execution plan) kaydedebilmenizi sağlar. Yazmış olduğunuz dinamik kodun tekrar kullanılma şansı çok az ise, yürütme planının kaydedilmesinin bir önemi olmaz. Çünkü aynı kod belirli süre içerisinde tekrar çağrılmadığında kayıtlı olan yürütme planı bir süre sonra önbellekten silinir. Bir uygulama planının kaydedilip kaydedilmeyeceği önemlidir ve göz önünde bulundurulmalıdır. Ayrıca sp_executesql ile çalıştırdığınız kod parametreli yapıya sahip değilse performans tasarrufu sağlamayacaktır.
- İstatistikleri güncel tutun
İstatistikler, tablonuzdan veri okurken kullanılacak en iyi indeksi (ing. index) seçmek için SQL Server Query Optimizer tarafından kullanılır. Eğer indekslere ait istatistikleriniz güncel değilse SQL Server verileri okurken en uygun olan indeksi belirleyemez ve bu da veri okuma performansının düşmesine neden olur.
- Veritabanı yöneticisi görevlerini aklınızda bulundurun.
Performans söz konusu olduğunda veritabanı yönetimi görevlerini ihmal etmemeniz gerekir. Örneğin, veritabanı yedeklerinin (ing. backup), istatistik güncellemelerinin, DBCC kontrollerinin ve indeks yeniden yapılandırmalarının (ing. index rebuilds) sistemleriniz üzerindeki etkilerini göz önünde bulundurun. Bu işlemleri test ve performans analizinize dâhil edin.
Yazar: 14 Aralık 2017, Hovhannes Avoyan (https://www.monitis.com/blog/author/havoyan/)
Türkçe’ye çeviren: 4 Ekim 2019, C. Sunguray
Orijinal makale: https://www.monitis.com/blog/30-ms-sql-p...ance-tips/