SQL Server üzerinde bir uygulama yavaşladığında ilk öneri çoğu zaman daha fazla işlemci veya bellek olur. Kaynak ihtiyacı gerçekten artmış olabilir; ancak kötü bir sorgu planı, kilit beklemesi veya değişen iş yükü de aynı belirtiyi yaratabilir. Kalıcı çözüm için hangi işlemde neyin beklendiğini ölçmek gerekir. Performans değerlendirmesi, tek bir kullanım grafiğine dayanarak yapılmamalıdır.
Bu yazı kurulum veya otomatik ayar betiği değil, ilk inceleme için bir karar akışıdır. Örnek yaklaşım, desteklenen SQL Server sürümü ve yönetim araçları bulunan bir ortamı varsayar. Gerçek veritabanında değişiklik yapmadan önce sürüm, yetki, bakım ve geri dönüş koşulları belirlenmelidir. Özellikle yüksek etkili komutları internetten kopyalayarak çalıştırmak sağlıklı bir teşhis yöntemi değildir.
1. Yavaşlığın ölçüsünü tanımlayın
Hangi ekran veya işlem ne kadar sürüyor? Sorun bütün gün mü, yalnızca belirli saatlerde mi görülüyor? Aynı veri hacminde önceki döneme göre bir fark var mı? Uygulama ekibiyle birlikte temsilî bir işlem seçin. “Veritabanı yavaş” ifadesini, ölçülebilir bir işleme dönüştürmeden sonuç karşılaştırmak zordur.
Son değişiklikleri listeleyin: uygulama sürümü, veri büyümesi, indeks değişikliği, bakım işi veya başka bir yük. Aynı saate denk gelen yedekleme ve raporlama görevlerini de görün. Bu bilgiler neden-sonuç ilişkisinin kanıtı değildir, ancak inceleme alanını daraltır. Başlangıçta eldeki varsayımları bulgulardan ayırın.
2. Kaynak tüketimi ile beklemeyi birlikte okuyun
Yüksek CPU, bellek baskısı, depolama gecikmesi ve kilit beklemeleri farklı araştırma yolları gerektirir. Bir sorgunun uzun sürmesi, bütün süre boyunca işlemci kullandığı anlamına gelmez. Bekleme türü ve süresi, iş yükünün nerede durduğunu anlamaya yardımcı olabilir. Tek bir anlık ekran görüntüsü yoğun dönemin tamamını temsil etmeyebilir.
Sunucu dışındaki bileşenleri de dikkate alın. Uygulama ile veritabanı arasındaki ağ gecikmesi veya çok sayıda küçük çağrı, veritabanı kaynakları normal görünürken kullanıcıyı bekletebilir. Aynı şekilde uygulamanın bağlantı havuzu davranışı sorun yaratabilir. Veritabanı ve uygulama ekipleri aynı zaman aralığını incelemelidir.
3. Query Store ile geçmişi kullanın
Microsoft Query Store dokümanı, sorgu, plan ve çalışma istatistikleri geçmişinin incelemedeki rolünü açıklar. Query Store'un mevcut durumu ve kapsamı sürümle birlikte değerlendirilmelidir. Her ortamda aynı varsayılan ayarın bulunduğunu kabul etmeyin.
Query Store etkinse, şikâyet saatindeki pahalı veya gerilemiş sorguları önceki dönemle karşılaştırın. Çalışma sayısı, süre ve plan değişimini aynı bağlamda okuyun. Daha uzun toplam süre, sorgunun tek çalışmada yavaşlamasından değil çok daha sık çalıştırılmasından kaynaklanabilir. Bu iki duruma aynı müdahale yapılmamalıdır.
4. Sorgu planını iş yükü bağlamında inceleyin
Plan üzerinde yüksek maliyetli görünen bir adım, tek başına değişiklik kararı değildir. Tahmin ve gerçek satır sayısı, kullanılan indeksler, veri dağılımı ve parametreler birlikte değerlendirilir. Laboratuvarda hızlı çalışan bir sorgu, üretimdeki veri hacmi veya eşzamanlılıkta farklı davranabilir. Test verisinin temsil gücü önemlidir.
Eksik indeks önerisini doğrudan uygulamadan önce mevcut indeksleri ve yazma maliyetini inceleyin. Fazla indeks, veri değişikliklerinin ve bakımın maliyetini artırabilir. Benzer şekilde bir planı zorlamak kısa vadede sorunu azaltabilse de bütün parametre veya veri düzenleri için kalıcı çözüm olmayabilir. Öneri, beklenen etki ve geri dönüş koşuluyla kaydedilmelidir.
5. Kilitlenme ile normal kilit beklemesini ayırın
Eşzamanlı işlemlerde bazı beklemeler normal işleyişin parçasıdır. Uzun süren transaction veya uygulamanın açık bıraktığı işlem ise diğer oturumları gereksiz bekletebilir. Hangi oturumun neyi tuttuğu ve iş işleminin neden tamamlanmadığı araştırılmalıdır. Bir oturumu sonlandırmak, veri ve uygulama tarafında geri alma süreci başlatabilir.
Sorunu çözmek için genel olarak kirli okuma yaklaşımına geçmek doğru bir başlangıç değildir. Tutarlılık ihtiyacı, sorgu tasarımı ve transaction kapsamı birlikte ele alınır. Muhasebe, stok ve raporlama işlerinin aynı veri doğruluğu beklentisine sahip olduğunu varsaymayın. Uygulama sahibi, teknik tercihin iş sonucunu anlamalıdır.
6. Tek değişiklik yapıp sonucu ölçün
Bir bakım penceresinde birçok ayarı aynı anda değiştirirseniz hangi adımın fayda sağladığını anlamak zorlaşır. Önce düşük riskli ve kanıtla desteklenen öneriyi seçin. Öncesi ve sonrası aynı işlem, benzer yük ve aynı ölçüm yöntemiyle karşılaştırılmalıdır. Yalnızca ortalama süre değil, hata ve uç değer davranışı da izlenmelidir.
Varsayımsal bir raporda toplam sürenin düşmesi iyi sonuçtur; ancak başka işlemlerin süresi yükseldiyse değerlendirme tamamlanmış değildir. İyileştirmenin bütün iş yüküne etkisini görün. Değişiklik kaydı, test sonucu ve geri dönüş yöntemi sonraki bakımda tekrar kullanılabilir bilgi üretir. CieloSync ile veritabanı, uygulama ve altyapı performansını birlikte değerlendirebilirsiniz.