Merhaba Salı, Çarşamba ve Perşembe günkü ziyaretlerimde performans konusunda çalıştık. DSMARTDB sunucusunda öncelikle sistem bazında performans incelemesi yapıldı. Sistem bazında yapılan performans analizinin çıktısını ekte bulabilirsiniz. (PERFORMANCE_ANALYSIS_1.rar) Bu çalışma sonrasında darboğaz yaşanan yerin IO olduğunu, bunun yanı sıra sistemin memorysinin arttırılmasının data cahce boyutunu arttırması nedeniyle IO sistemini bir parça rahatlatacağı düşünülerek sistemin memory ‘si arttırıldı. Sistemde AdHoc sorgu kullanımı yoğun olduğu için instance bazında “optimize for ad hoc workloads” parametresi set edildi. Db bazına ise parameterization modeli SIMPLE ‘dan FORCED ‘e alındı. Bu sayede hem plan cache kullanımı eskisine gore daha optimal bir kullanım kazandı hem de CPU kullanımı düştü. Ancak dikkat edilmesi gereken nokta AdHoc query kullanımı yerine sp kullanımı tercih edilmesi gerektiğidir. Bu sayede sistem kaynaklarının daha düzgün ve verimli kullanılması sağlanabilir. Sistem bazında yapılan bu iyileştirmelere parallel olarak sistemde IO bazında maliyet yaratan query ‘ler incelendi. Gereken query ‘ler için uygun indexler yaratıldı. Uygulamada değişiklik gerektiren queryler ve öneriler ilgili yazılım grupları ile paylaşıldı. Data boyutu fazla olduğu için maliyet yaratan iki adet tablodaki eski kayıtlar ilgili yazılım gruplarından alınan kritere gore bir arşiv tablosuna akatarıldı. (Aktif tablolardan arşive data taşıyan ve aktif tablodan ilgili datayı silen job’ların yaratılması gereklidir.) Tempdb ‘deki datafile contention ‘un azaltılmasına yönelik olarak tempdb ‘ye datafile eklendi. Autoshrink enable edilmiş db ‘lerde autoshrink disable edildi. HYDRA sunucusunda maliyet oluşturan query ‘ler incelendi. Uygulamada değişiklik gerektiren queryler ve öneriler ilgili yazılım grupları ile paylaşıldı. Bu çalışmaları yaparken aldığım notlar da ekte görüşlerinize sunulmuştur. (DSMART_Performance_Tuning.docx) Performans ile alakalı olmasa da çalışma sırasında öğrendiğim ve büyük bir risk oluşturan bir durumu da burada belirtmek istiyorum. Öğrendiğim kadarıyla kodun içerisinde sa kullanıcısı kullanılıyor ve sa kullanıcısının şifresi uygulama gruplarınca bilinir durumda. Bu çok ciddi sonuçlar doğurabilecek riskler içeriyor. Sa kullanıcısın şifresinin değiştirilmesi ve uygulamaların sadece gereken haklara sahip kendi kullanıcıları ile SQL Server ‘a bağlanmalarının sağlanması öncelikle değerlendirilmesi gereken konulardan biri olarak öne çıkıyor. Saygılarımla. Hakan.
