SQL Server Performans Ayarında Sık Yapılan 12 Hata ve Yerine Yapılması Gerekenler

SQL Server performans sorunlarının önemli bir kısmı, sorunun kendisinden çok ona verilen tepkiden büyür. Panikle yeniden başlatılan bir sunucu, bilinçsizce eklenen index’ler, sunucu genelinde kapatılan paralellik ya da ölçmeden yapılan beş değişiklik aynı anda; hepsi kısa vadede bir şey yapmış olma hissi verir, uzun vadede ise sorunu gizler ya da büyütür.

Bu yazıda sahada en sık karşılaştığımız performans ayarı hatalarını, neden zararlı olduklarını ve bunların yerine ne yapılması gerektiğini topluyoruz.

1. Önce Yeniden Başlatmak

Yeniden başlatma, sorunun kanıtını (çalışan istekler, bekleme istatistikleri, plan cache) siler. Uzun transaction’lar varsa veritabanı uzun bir recovery sürecine girer ve kesinti, yeniden başlatmadan önceki halinden daha uzun sürer. Önce içeri bakın; sunucu yanıt vermiyorsa DAC ile bağlanın.

2. Herkesin Aynı Anda Müdahale Etmesi

Kriz anında biri sanal makinenin kaynaklarını değiştirir, biri oturumları sonlandırır, biri plan cache’i temizler, biri MAXDOP’u düşürür. Sonuçta hangi adımın neyi değiştirdiği bilinmez. Tek bir kişi yönetsin, her adım kaydedilsin. Bu yaklaşımı kesinti runbook’umuzda anlatıyoruz.

3. Plan Cache’i ve Buffer Pool’u Temizlemek

DBCC FREEPROCCACHE ve DBCC DROPCLEANBUFFERS üretimde sorunu çözmez: tüm sorgular yeniden derlenir, veriler diskten yeniden okunur ve kısa süreli bir CPU ve I/O fırtınası yaşanır. Kötü bir plan varsa yalnızca o planı hedefleyin ya da Query Store ile iyi planı zorlayın.

4. MAXDOP’u Sunucu Genelinde 1 Yapmak

Yüksek CXPACKET beklemelerine verilen bu tepki, paralelliği tamamen kapatır; raporlar, index bakımı ve CHECKDB dramatik şekilde yavaşlar. Doğru yaklaşım, MAXDOP ve cost threshold değerlerini önerilen aralığa getirmek ve paralel çalışan pahalı sorgulara bakmaktır.

5. Eksik Index Önerilerini Körü Körüne Uygulamak

Missing index DMV’leri ve execution plan’daki yeşil öneriler, tek bir sorguya bakarak üretilir. Hepsini uygulamak, aynı kolonları içeren düzinelerce benzer index’e, yavaşlayan yazma işlemlerine ve şişen bakım sürelerine yol açar. Önerileri mevcut index’lerle birleştirerek değerlendirin; ayrıntılar index rehberimizde.

6. Her Gece Tüm Index’leri Rebuild Etmek

Parçalanma oranına bakmadan her gece her index’i yeniden oluşturmak, log’u şişirir, Always On secondary’lerine gereksiz yük bindirir ve bakım penceresini doldurur. Parçalanmaya ve sayfa sayısına göre karar veren bir bakım ve düzenli istatistik güncellemesi çok daha verimlidir.

7. Her Sorguya NOLOCK Eklemek

NOLOCK (READ UNCOMMITTED) blocking’i azaltır ama kirli okumalara, aynı satırı iki kez okumaya ya da hiç okumamaya yol açabilir. Finansal raporlarda yanlış sonuç, kilitlenmeden daha pahalıdır. Okuma ve yazma çakışmaları için read committed snapshot isolation (RCSI) genellikle çok daha güvenli bir çözümdür.

8. Veritabanını Shrink Etmek

Disk alanı kazanmak için düzenli shrink, ciddi index parçalanmasına ve ardından dosyanın yeniden büyümesine yol açar. Bkz. shrink rehberimiz.

9. Ölçmeden Değiştirmek

Baseline olmadan yapılan bir değişikliğin işe yarayıp yaramadığını kimse bilemez. Değişiklikten önce ve sonra aynı ölçümü (sorgu süresi, okuma, CPU, bekleme istatistikleri) alın ve her seferinde tek bir şeyi değiştirin.

10. Execution Plan’a Bakmamak

Bir sorgunun neden yavaş olduğunun cevabı çoğu zaman planındadır: büyük tablo taramaları, örtük tip dönüşümleri, tahmini ve gerçek satır sayısı arasındaki büyük farklar. Plan okumadan yapılan tuning tahmindir. Pahalı sorguları bulmak için yavaş sorgu rehberimize bakın.

11. İlk Çözümü Donanımda Aramak

Daha fazla CPU ya da bellek, verimsiz bir sorguyu bir süre gizleyebilir ama düzeltmez; SQL Server çekirdek bazında lisanslandığı için de kalıcı bir maliyet yaratır. Önce iş yükünü ölçün.

12. Performansı Konuşurken Yedeği ve CHECKDB’yi Unutmak

Performans şikâyetiyle başlayan incelemelerde en sık bulduğumuz iki sorun, aslında performansla ilgili değildir: iş biriminin RPO ve RTO hedefleriyle uyumlu bir yedek planı yoktur ve DBCC CHECKDB düzenli çalışmaz. Hızlı ama geri dönülemeyen bir veritabanı, yavaş bir veritabanından çok daha büyük bir risktir.