SQL Server Performans Sorunlarını Belirleyen Kırmızı Bayraklar

SQL Server performance monitoring queries konusunda şunu biliyor musunuz?
Hatalı yazılmış sorgular, veritabanı boyutlarının beklenmedik şekilde %300’e kadar büyümesine neden olabilir ve sistem performansını ciddi şekilde etkileyebilir.
Gerçek performans problemleri genelde sistem loglarında değil, sorgu alışkanlıklarında gizlidir.

SQL Server, sorgularınızın kaç satır döndüreceğini tahmin etmek için istatistikleri kullanır.
Ancak bu tahminler 10 kat veya daha fazla sapma gösterdiğinde, sorgularınız yeterince bellek veya CPU kaynağı alamadığı için performans sorunları yaşarsınız.
Bu nedenle SQL Server performans sorunları çoğunlukla:

• Güncel olmayan istatistikler
• Eksik indeksler
• Bloklamalar

gibi faktörlerden kaynaklanır. Özellikle sorguların Table Scan yapması, parametre hassasiyetli planlar ve güncellenmeyen istatistikler, en yaygın sorunlar arasındadır.

✅ Doğru index +
✅ Güncel istatistik +
✅ Etkili izleme = Performansın güçlü sacayağıdır.

SQL Server 2022+ ile gelen PSPO (Parameter Sensitive Plan Optimization) özelliği, yıllardır çözülemeyen bir baş ağrısına neşter vurdu. Bununla birlikte, kötü yazılmış bir sorguya hiçbir versiyon ilaç olamaz.

Bu makalede, SQL Server’da performansı etkileyen kırmızı bayrakları tespit etmeyi, bunlara yönelik uzman çözümleri öğrenmeyi,performans darboğazlarını aşmayı ve veritabanı sistemlerinizi optimize etmeyi adım adım ele alacağız.

SQL Server performansınız düşüyor ama nedenini bilmiyor musunuz?

Performans sorunları yaşadığınızda önce neyi kontrol edersiniz? Çoğu zaman CPU veya RAM değerlerine bakarız, ancak asıl sorun daha derinde olabilir. Araştırmalar gösteriyor ki, optimize edilmemiş sorgular gerekenden %70’e varan oranda daha fazla kaynak tüketebilir. İşte bu noktada SQL Server’ın bize ne söylemeye çalıştığını anlamak kritik öneme sahip.

Sorguların Table Scan yapması

SQL Server sorguları çalıştırırken iki temel yaklaşım kullanır: seek (hedefli arama) ve scan (tam tarama). Table Scan veya Index Scan, SQL Server’ın bir sorguyu çalıştırmak için tüm tabloyu veya indeksi baştan sona okuması anlamına gelir. Bu, küçük tablolarda sorun oluşturmaz, fakat verileriniz büyüdükçe performans ciddi şekilde düşer.

Table Scan işlemi nasıl anlaşılır? Execution Plan’ı incelediğinizde “Clustered Index Scan” veya “Table Scan” operatörlerini görürsünüz. Bu, SQL Server’ın verileri bulmak için indeks yapısını etkili kullanamadığını gösterir. Özellikle WHERE koşullarında kullanılan sütunlar için uygun indeksler yoksa, SQL Server tüm tabloyu taramak zorunda kalır.

Örneğin, milyonlarca satıra sahip bir müşteri tablosunda belirli bir şehirdeki müşterileri arıyorsanız ve şehir sütunu için indeks yoksa, her sorgu tüm tabloyu tarayacak ve performans zamanla daha da kötüleşecektir.

Çözüm: Missing Index DMVs, Include Column kullanımı

SQL Server, eksik indeksleri tespit etmenize yardımcı olan “Missing Index” DMV’lerini (Dynamic Management Views) sunar. Bu görünümler, sorgu performansını önemli ölçüde artırabilecek indeksleri belirlemenizi sağlar. Kullanabileceğiniz temel DMV’ler şunlardır:

• sys.dm_db_missing_index_details: Eksik indeks hakkında ayrıntılı bilgiler sunar
• sys.dm_db_missing_index_group_stats: Eksik indeks uygulandığında elde edilebilecek performans iyileştirmelerini gösterir
• sys.dm_db_missing_index_groups: Eksik indeks grupları hakkında bilgi sağlar

SQL Server’ın önerdiği indeksler her zaman olduğu gibi uygulanmamalıdır. Bunlar, indeks analizi yaparken değerlendirmeniz gereken kaynaklardan sadece biridir.

INCLUDE ifadesi, nonclustered indekslere anahtarsız (nonkey) sütunlar eklemenize olanak tanır. Bu sayede, sorgunuzda kullanılan tüm sütunlar indekse dahil edilerek performans önemli ölçüde artırılabilir. Bir indeks, sorguda kullanılan tüm sütunları içerdiğinde “sorguyu kapsıyor” (covering the query) olarak nitelendirilir ve SQL Server’ın tablo veya kümelenmiş indeks verilerine erişmesi gerekmez.

Demo ile “öncesi-sonrası” performans farkı

Örnek bir senaryo düşünelim: Person.Address tablosunda PostalCode sütununa göre arama yapan ancak AddressLine1, AddressLine2, City ve StateProvinceID sütunlarını da döndüren bir sorgu. Önce basit bir indeks oluşturalım:

CREATE INDEX IX_Address_PostalCode ON Person.Address (PostalCode)

Bu indeksle sorgu çalıştırıldığında, SQL Server önce indeksi kullanarak PostalCode değerlerini bulur, ardından her satır için tabloya giderek diğer sütunları alır (key lookup). Bu durum, mantıksal okuma sayısının 7.907’ye ulaşmasına neden olabilir.

INCLUDE kullanan geliştirilmiş indeksle:

CREATE INDEX IX_Address_PostalCode ON Person.Address (PostalCode) 
INCLUDE (AddressLine1, AddressLine2, City, StateProvinceID)

Aynı sorgu artık tüm verileri doğrudan indeksten alabilir ve mantıksal okuma sayısı 19’a düşebilir. Bu da sorgunun CPU kullanımını sıfıra yaklaştırabilir ve çalışma süresini %40’tan fazla azaltabilir.

Doğru index + güncel istatistik + etkili izleme = performansın üçlü sacayağıdır. İndeks oluştururken şunlara dikkat etmelisiniz: WHERE koşulunda kullanılan sütunlar anahtar sütunlar olmalı, SELECT listesindeki diğer sütunlar ise INCLUDE ile eklenmelidir. Böylece hem arama hızlı olur hem de ek tablo erişimi ortadan kalkar.

Kırmızı Bayrak #1:

Bir SQL Server veritabanında performans sorunlarıyla karşılaştığınızda, ilk kontrol etmeniz gereken kırmızı bayrak genellikle eksik veya hatalı indeks kullanımıdır. İndeksler, veritabanı performansını artırmak için kritik öneme sahiptir, ancak eksik veya parçalanmış indeksler sorgu yürütme süresini önemli ölçüde yavaşlatabilir.

İndeks sorunları, SQL Server’ın tablolarda tam tarama (Table Scan) yapmasına neden olur. Bu durum, SQL Server’ın ilgili verileri hızlıca almak yerine tüm tabloyu baştan sona taramak zorunda kalması anlamına gelir. Execution Plan’da kırmızı renkle gösterilen operatörler, genellikle eksik sütun istatistikleri gibi uyarıları işaret eder ve derhal çözülmelidir.

Eksik veya yanlış indeks kullanımının belirtileri şunlardır:

• Graphical Showplan’da yüksek maliyet oranları: Execution Plan’da en yüksek maliyet yüzdesine sahip operatörleri arayarak öncelikli sorunları belirleyebilirsiniz.
• Execution Plan’da “Table Scan” veya “Clustered Index Scan” operatörleri: Özellikle büyük tablolarda bu operatörlerin görülmesi, indeks eksikliğinin açık bir göstergesidir.
• Yüksek CPU ve bellek kullanımı: İndeks eksikliği, gereksiz işlemler için CPU ve bellek kaynağı harcanmasına neden olur.

Bu sorunları çözmek için öncelikle SQL Server’ın dahili araçlarını kullanarak eksik indeksleri tespit etmelisiniz. sys.dm_db_missing_index_details DMV’si, performansı önemli ölçüde artırabilecek eksik indeksleri belirlemenizi sağlar. Ayrıca, Database Engine Tuning Advisor veya SQL Diagnostic Manager gibi araçları kullanarak indekslerinizi düzenli olarak gözden geçirip optimize edebilirsiniz.

İndeksleri oluştururken veya yeniden düzenlerken şu noktalara dikkat etmelisiniz:

• Düşük fragmantasyon için düzenli bakım planları oluşturun (%30’un altında = yeniden düzenleme; %30’un üstünde = yeniden oluşturma).
• WHERE veya JOIN koşullarında kullanılan sütunlar için uygun indeksler oluşturun.
• Fonksiyonlarla sarılmış sütunların (non-SARGable) indeks kullanımını engellediğini unutmayın.

İndeks sorunlarını tespit etmek için kullanabileceğiniz etkili bir yöntem, sys.dm_exec_query_stats ve plan analizini kullanarak yüksek mantıksal okuma sayısına sahip sorguları belirlemektir. Bununla birlikte, indeksleme stratejinizi oluştururken veritabanınızın hem okuma hem de yazma gereksinimlerini dengelemelisiniz. Çünkü her indeks, veri değişikliklerinde ek yük getirir.

Unutmayın ki doğru index + güncel istatistik + etkili izleme = performansın üçlü sacayağıdır. Dolayısıyla, indeks stratejinizi oluştururken tablolarınızın boyutunu, sorgu desenlerinizi ve uygulamanızın genel performans gereksinimlerini göz önünde bulundurmalısınız.

İndex Yokluğu veya Yanlış İndex Kullanımı

Veritabanınız büyüdükçe indeks seçimleri kritik hale gelir. Heap tabloları (indekssiz tablolar) hiçbir şekilde mantıksal veya fiziksel olarak sıralanmayan veri yığınlarıdır ve neredeyse her zaman performans sorunlarına yol açar. Bu tür tablolar, SQL Server’ın daha fazla I/O işlemi yapmasına neden olur ve veri organizasyonu olmadığından sorgular yavaşlar.

İndekslerle ilgili sorunlar sadece yokluklarıyla sınırlı değildir. Bazen SQL Server, mevcut indeksler arasından yanlış seçimler yapabilir. Bu durum genellikle hatalı kardinalite tahminlerinden kaynaklanır. Sorgu optimize edici, bir birleştirme işleminin gerçekte olduğundan çok daha fazla satır döndüreceğini tahmin ettiğinde, daha verimli bir indeksi göz ardı edebilir.

İndeks fragmantasyonu da sorgularınızı yavaşlatan önemli bir faktördür. Yüksek düzeyde parçalanmış indeksler, özellikle çok sayıda sayfayı okuyan tam veya aralık taramaları kullanan sorgular için performansı düşürür. Depolama alt sisteminiz sıralı I/O’yu rastgele I/O’dan daha iyi gerçekleştirdiğinde, indeks parçalanması performansı olumsuz etkiler çünkü parçalanmış indeksleri okumak için daha fazla rastgele I/O gerekir.

SQL Server, eksik indeksler konusunda size yardımcı olabilecek dahili araçlar sunar. Missing Indexes özelliği, sorgu performansını önemli ölçüde artırabilecek eksik indeksler hakkında bilgi sağlar. Bu özellik iki bileşenden oluşur:

• Execution plan XML’indeki MissingIndexes öğesi
• Eksik indeksler hakkında bilgi döndüren DMV’ler (Dynamic Management Views)

Ancak bu öneriler tam olarak uygulanmamalıdır. Missing Index önerileri sadece indeks analizi yaparken kullanabileceğiniz kaynaklardan biridir. Önerilen indeksler genellikle aynı tablo ve sütun(lar) üzerinde benzer varyasyonlar sunabilir ve mevcut indekslerle çakışabilir. Optimal performans için, eksik indeksleri ve mevcut indeksleri çakışma açısından incelemek ve yinelenen indeksler oluşturmaktan kaçınmak önemlidir.

İndeks eklemeden önce, her indeks eklemenin INSERT, UPDATE ve DELETE işlemlerini hafifçe yavaşlattığını unutmayın. Bu, indeksin her veri değişikliğinde güncellenmesi gerektiği içindir. Bu nedenle, çok fazla indeks sistemi yavaşlatabilir ve özellikle yazma işlemi yüksek olan tablolarda performans sorunlarına neden olabilir.

Sonuç olarak, indeks stratejinizi oluştururken hem okuma hem de yazma gereksinimlerinizi dengeleyin. Genellikle normalleşme ve tablo aktivitesi seviyesine bağlı olarak bir tabloda 3-5 indeks bulunur. Yazma yüzdesi yüksek tablalarda 3-5 indeksi hedefleyin, okuma yüzdesi yüksek tablalarda ise daha fazla indeks kullanabilirsiniz. Doğru index + güncel istatistik + etkili izleme = performansın üçlü sacayağıdır.

Kırmızı Bayrak #2:

Parametre değerlerine göre sorgu performansının değişmesi, SQL Server’da en sinsi sorunlardan biridir. Aynı sorgu bazen saniyeler içinde tamamlanırken, bazen dakikalarca sürebilir. Bu durum, SQL Server’ın sorgu planlarını nasıl önbelleğe aldığı ve farklı parametre değerleriyle nasıl kullandığıyla ilgilidir.

Parametre Hassasiyetli Planlar (PSP) sorunu, temelde sorgu optimize edicinin parametre değerlerini bilmeden plan oluşturmasından kaynaklanır. SQL Server, yerel değişkenler kullanıldığında, değişkenlerin gerçek değerlerini bilmeden planı oluşturur ve BETWEEN önermesi ile iki bilinmeyen değer için varsayılan tahmin %9‘dur. Bu, gerçekte döndürülecek satır sayısı ile tahmini satır sayısı arasında büyük farklara yol açabilir.

Bu sorunun en belirgin göstergesi, Execution Plan’da “tahmin edilen satır sayısı” ile “gerçek satır sayısı” arasında önemli farklılıklar olmasıdır. Eğer sorgunuz 1,000 satır döndüreceği tahmin edilirken 1,000,000 satır işliyorsa, bu durum kötü bir plan seçimine işaret eder. Bu da performansı ciddi şekilde etkiler.

Örnek bir senaryo düşünelim:

Müşteri tablosunda PostalCode sütununa göre filtreleme yapan bir stored procedure var. ‘06100’ değeri için birkaç yüz kayıt dönerken, ‘34000’ için binlerce kayıt dönüyor. SQL Server ilk çalıştırmada düşük kayıt sayısı için optimize edilmiş bir plan oluşturur ve önbelleğe alır. Ancak daha sonra çok sayıda kayıt gerektiren parametre değeriyle çağrıldığında, aynı (artık uygunsuz olan) planı kullanmaya devam eder ve performans düşer.

Parametre hassasiyeti sorunu için çözüm yolları:

1. OPTION (RECOMPILE) komutu: Bu komut, her çalıştırma için planın yeniden derlenmesini sağlar. Böylece SQL Server, gerçek parametre değerlerini kullanarak her seferinde en iyi planı oluşturabilir. Ancak bu yaklaşım, sık çalıştırılan sorgularda derleme yükü getirebilir.
2. SQL Server 2022+ için PSPO özelliği: Parameter Sensitive Plan Optimization, SQL Server’ın farklı parametre değerleri için çoklu planlar önbelleğe almasını sağlayan yeni bir özelliktir. Bu sayede SQL Server yıllardır çözülmeyen bir baş ağrısına neşter vurmuş oldu.
3. Sorgu ipuçları: Sorgu iyileştirmelerinde, parametre yerine sabit değerler kullanmak veya değişken değil, parametre kullanmak fark yaratabilir.
4. Filtreleme mantığını değiştirmek: Parametre değerlerini mümkün olduğunca tanımlı aralıklara bölmek de etkili bir yöntemdir.

Sorgu performansı izleme konusunda, sys.dm_exec_query_stats ve plan önbelleğini analiz ederek parametre hassasiyetine duyarlı sorguları tespit edebilirsiniz. Performans sorunlarının büyük kısmı genellikle sistem loglarında değil, sorgu alışkanlıklarında gizlidir. Unutmayın ki, kötü yazılmış bir sorguya hiçbir versiyon ilaç olamaz. Bu yüzden doğru index + güncel istatistik + etkili izleme = performansın üçlü sacayağıdır.

Parametre Hassasiyetli Planlar (PSP) – Aynı Sorgu, Farklı Felaket

SQL Server’da performans sorunlarının en karmaşık sebeplerinden biri, aynı sorgunun farklı parametre değerleriyle yürütüldüğünde çok farklı performans göstermesidir. Bu durum “parametre koklama” (parameter sniffing) olarak bilinir ve sorgular için felaket senaryolar yaratabilir.

Özellikle değişken sayıya göre gelen sonuçlar

Parametre hassasiyetli planlar sorunu, SQL Server’ın bir sorgu için oluşturduğu execution planı önbelleğe alması ve sonraki çalıştırmalarda ilk parametre değerlerini temel alarak bu planı tekrar kullanmasından kaynaklanır. Örneğin, bir müşteri siparişleri tablosunda @History_Date parametresi için “10-10-2024” değeriyle sorgu ilk kez çalıştırıldığında, SQL Server o güne özel bir plan oluşturur. Fakat parametre değeri “01-01-2023” gibi çok daha fazla kayıt döndüren bir tarihe değiştiğinde, önceki plan artık optimal olmaz.

Bu sorun özellikle düzgün dağılmayan verilerde (non-uniform data distributions) ortaya çıkar. Aynı stored procedure bazı parametrelerle saniyeler içinde çalışırken, farklı parametre değerleriyle dakikalar sürebilir. Bu durumda kullanıcılar sistemin donduğunu düşünür, ama gerçekte sorun parametre hassasiyetidir.

Sorgu içindeki şöyle bir yapı vardığında problem daha da belirginleşir:

WHERE (col1 = @col1 OR @col1 IS NULL)

Bu tür sorgularda SQL Server genellikle tablo tarama (table scan) yapmayı tercih eder, çünkü NULL durumunu karşılayabilmek için indeks kullanımını optimize edemez.

Çözüm: OPTION (RECOMPILE) veya SQL Server 2022+ için PSPO özelliği

Bu sorunla başa çıkmanın en basit yolu OPTION (RECOMPILE) ipucunu kullanmaktır. Bu ipucu, SQL Server’ın her çalıştırmada sorguyu yeniden derlemesini ve o anki parametre değerlerine göre optimize etmesini sağlar. Basit sorgularda yeniden derleme maliyeti çok düşüktür ve performans kazanımı genellikle bu maliyetten çok daha yüksektir. Ancak, çok sık çalıştırılan karmaşık sorgularda bu yöntem CPU kullanımını artırabilir.

Bununla birlikte, SQL Server 2022+ ile gelen PSPO (Parameter Sensitive Plan Optimization) özelliği, yıllardır çözülmeyen bu baş ağrısına neşter vurdu. PSPO, tek bir parametreli sorgu için farklı veri boyutlarına göre üç farklı execution plan önbelleğe alabilir. Sistem, düşük, orta ve yüksek kardinalite aralıkları için ayrı planlar oluşturur ve çalışma zamanında parametre değerine göre en uygun planı seçer.

Bu özelliği kullanmak için veritabanınızın uyumluluk seviyesini 160 veya üzerine ayarlamanız yeterlidir. Özellikle veri ambarlarında, Guy Glantser’in önerisiyle, “Her sorguya varsayılan olarak OPTION (RECOMPILE) ekle” yaklaşımı benimsenebilir.

Ancak unutmamak gerekir ki, kötü yazılmış bir sorguya hiçbir versiyon ilaç olamaz. Bu yüzden doğru index + güncel istatistik + etkili izleme = performansın üçlü sacayağıdır.

Kırmızı Bayrak #3:

Blocking ve deadlock sorunları, SQL Server performansını sessizce öldüren en tehlikeli faktörlerdendir. Kullanıcılar işlemlerin uzun sürdüğünü veya sistemin donduğunu söylediğinde, çoğu zaman arka planda veri erişim kilitlenmeleri yaşanıyordur. Bu sorunlar, kullanıcılar sistemin tamamen yanıt vermediğini düşündüğünde bile, aslında SQL Server’ın hâlâ çalıştığını gösterir.

Blocking & Deadlock – Sessiz Performans Katili

Kilitleme (lock) mekanizması, veritabanı sistemlerinde kaynakları korumak için kullanılır. Ancak kilitler uzun süre tutulduğunda ve diğer oturumlar bu kilitleri beklemek zorunda kaldığında, blocking (blokaj) senaryosu oluşur. Kısa süreli blokajlar her veritabanı sisteminde normal kabul edilir, fakat uzun süreli bloklamalar, özellikle çoğu sorgunun kilit beklediği durumlarda, tüm sunucunun yanıt vermediği izlenimini yaratabilir.

Gerçek bir senaryo: Kullanıcı sistem dondu dediğinde arka planda neler oluyor?

Kullanıcı “sistem dondu” dediğinde, genellikle şunlardan biri gerçekleşir:

1. Başlıca blokaj zinciri: Bir sorgu veya işlem, uzun süre kilitleri elinde tutar ve diğer tüm kullanıcılar bu kilitlerin serbest bırakılmasını bekler. Bu sırada sistem kullanıcılara “donmuş” gibi görünür.
2. Yetim (orphaned) işlemler: Bazen uygulama sorunları nedeniyle işlemler açık kalabilir ve hiçbir sorgu aktif çalışmasa bile kilitler tutulmaya devam eder.
3. Scheduler sorunları: SQL Server’ın işbirlikçi zamanlama mekanizması (Schedulers) sorunlar yaşadığında, SQL Server thread’leri sorguları, oturum açma ve kapatma işlemlerini işlemeyi durdurabilir. Bunun sonucunda, SQL Server etkilenen scheduler sayısına bağlı olarak kısmen veya tamamen yanıtsız görünebilir.
4. I/O darboğazları: I/O yavaşlığı, sistemdeki çoğu sorguyu etkileyebilir. Eğer Avg Disk sec/Transfer performans monitör sayacı değerleri tutarlı olarak 10-15 milisaniyenin üzerindeyse, bir I/O sorunu var demektir.

Çözüm: sp_whoisactive, Extended Events ve Deadlock Graph

Blokaj sorunlarını çözmek için şu adımları izleyebilirsiniz:

• Baş blokaj oturumunu belirleyin: sys.dm_exec_requests DMV çıktısındaki blocking_session_id sütununu veya sp_who2 stored procedure çıktısındaki BlkBy sütununu inceleyerek blokaj zincirinin başını tespit edin.
• Adam Machanic’in sp_whoisactive stored procedure’ünü kullanın: Bu, aktif çalışan sorguları, kaynak kullanımını ve blocking bilgilerini gösterir.
• Extended Events kullanın: SQL Server performans sorunlarını izlemek için Extended Events güçlü bir araçtır. Özellikle sqlserver.blocked_process_report olayını izleyerek blokaj sorunlarını tespit edebilirsiniz.
• Deadlock Graph analizi yapın: SQL Server Management Studio’da yer alan Deadlock Graph görselleştirme aracı, kilitlenme döngülerini görselleştirmenize ve anlamanıza yardımcı olur.
• Transaction isolation seviyesini gözden geçirin: Sorguların transaction isolation seviyesini ayarlayarak blokaj süresini azaltabilirsiniz.

Sonuç olarak, blocking ve deadlock sorunları hakkında bilgi sahibi olmak ve bunları çözmek için doğru araçları kullanmak, SQL Server performans sorunlarını çözmenin kritik bir parçasıdır. Tıpkı doğru index + güncel istatistik + etkili izleme = performansın üçlü sacayağı olduğu gibi, etkili lock yönetimi de bu sacayağının ayrılmaz bir parçasıdır.

Blocking & Deadlock – Sessiz Performans Katili

_{Image Source: The Quest Blog – Quest Software}

Veritabanı performans sorunlarının en zor tespit edilen sebebi genellikle blocking ve deadlock durumlarıdır. Bu sorunlar sistemin yanıt vermesini engelleyerek kullanıcılara “donma” hissi verir. SQL Server’da blocking, bir oturumun tuttuğu kilidi başka bir oturumun beklemesi durumunda oluşur. Bu bekleme süresi uzadıkça, daha fazla oturum zincire eklenir ve tüm sistem yavaşlar.

Gerçek bir senaryo: Kullanıcı sistem dondu dediğinde arka planda neler oluyor?

Kullanıcılar “sistem dondu” dediğinde, genellikle sunucudaki sorgular blocking zincirine takılmış durumdadır. Bu durumda sistemdeki birçok sorgu, başlıca bloklayıcı oturum (lead blocker) tarafından tutulan kaynakları bekler. Bloklama durumunda sorguların “blocking_session_id” sütununda değer görürsünüz; bu, sorgunun hangi oturum tarafından engellendiğini gösterir.

Bazı durumlarda, VSS tabanlı yedekleme sistemleri (Azure Site Recovery, Veeam gibi) çok sayıda veritabanını aynı anda dondurduğunda da benzer semptomlar ortaya çıkar. KB #943471, bu yüzden 35’ten az veritabanının aynı anda yedeklenmesini önerir. Bu limit aşıldığında, yazma sorguları için bloklanma zincirleri oluşur ve okuyucular da etkilenir.

Deadlock ise daha ciddi bir durumdur; iki veya daha fazla işlemin döngüsel bağımlılık içinde birbirini engellemesidir. Örneğin:

• İşlem A, 1. satırdaki kilit üzerinde paylaşımlı kilide sahiptir
• İşlem B, 2. satırdaki kilit üzerinde paylaşımlı kilide sahiptir
• İşlem A, 2. satır üzerinde özel kilit istiyor ve İşlem B bitene kadar bekliyor
• İşlem B, 1. satır üzerinde özel kilit istiyor ve İşlem A bitene kadar bekliyor

Bu durumda SQL Server deadlock tespit edicisi devreye girer ve işlemlerden birini kurban olarak seçip sonlandırır, böylece diğeri devam edebilir.

Çözüm: sp_whoisactive, Extended Events ve Deadlock Graph

Blocking sorunlarını tespit etmek için Adam Machanic’in sp_whoisactive stored procedure’ü mükemmel bir araçtır. Bu araç @find_block_leaders = 1 parametresiyle çalıştırıldığında “blocked_session_count” sütununu döndürür ve başlıca bloklayıcıları gösterir. Ayrıca @get_locks = 1 parametresi “locks” adlı bir XML sütunu döndürür; buradan hangi nesnelerin kilitlendiğini görebilirsiniz.

Deadlock’ları izlemek için en etkili yöntem Extended Events‘tir. SQL Server 2012 ve sonraki sürümlerde, xml_deadlock_report XEvent’i deadlock grafiğini yakalar. Bu bilgilere system_health oturumundan şu sorguyla erişebilirsiniz:

SELECT xdr.value('@timestamp', 'datetime') AS [Date], 
       xdr.query('.') AS [Event_Data] 
FROM (SELECT CAST ([target_data] AS XML) AS Target_Data 
      FROM sys.dm_xe_session_targets AS xt 
      INNER JOIN sys.dm_xe_sessions AS xs 
      ON xs.address = xt.event_session_address 
      WHERE xs.name = N'system_health' 
      AND xt.target_name = N'ring_buffer') AS XML_Data 
CROSS APPLY Target_Data.nodes('RingBufferTarget/event[@name="xml_deadlock_report"]') 
AS XEventData(xdr) 
ORDER BY [Date] DESC;

Deadlock Graph analizi, sorunu çözmek için kritik öneme sahiptir. Grafikte üç temel öğe bulunur: süreç düğümleri (hangi işlemler çalışıyor), kaynak düğümleri (hangi nesneler kilitli) ve kenarlar (süreçler ve kaynaklar arasındaki ilişkiler).

Bununla birlikte, gerçek performans problemleri genelde sistem loglarında değil, sorgu alışkanlıklarında gizlidir. Bu yüzden doğru index + güncel istatistik + etkili izleme = performansın üçlü sacayağıdır.

Kırmızı Bayrak #4:

Güncel olmayan istatistikler, SQL Server performansını düşüren sessiz düşmanlardır. SQL Server sorgu optimizasyonu için istatistikleri kullanır – bunlar tabloların içeriği hakkında sayısal veri sağlayan küçük nesnelerdir. İstatistikler güncel olmadığında, SQL Server yanlış kardinalite tahminleri yapar ve sorgular için optimal olmayan planlar seçer.

İstatistik sorunlarını fark etmenin en belirgin işaretlerinden biri, tahmini ve gerçek satır sayıları arasındaki önemli farklardır. Execution Plan’da bir sorgunun 1.000 satır döndüreceği tahmin edildiğini, ancak gerçekte 1.000.000 satır işlediğini görürseniz, bu durum genellikle güncel olmayan istatistiklere işaret eder. Bu tür uyumsuzluklar, SQL Server’ın yanlış operatör seçimlerine yol açabilir.

Güncel olmayan istatistikler şu durumlarda ortaya çıkar:

• Auto Update Statistics özelliği kapatıldığında
• Güncelleme eşiği henüz aşılmadığında (varsayılan olarak tablodaki satırların %20’si değiştiğinde güncellenir)
• Çok büyük tablolarda istatistik güncellemeleri zamanında tamamlanamadığında

SQL Server istatistik sorunlarını tespit etmek için performans izleme araçlarını kullanabilirsiniz. Avg Disk Sec/Transfer sayacı tutarlı bir şekilde 10-15 milisaniyeyi aşıyorsa, I/O performans sorunlarına işaret eder ve bu genellikle istatistik sorunlarından kaynaklanabilir. Ayrıca, performans izleme verileriniz anlamlı olması için mutlaka referans değerleri (baseline) oluşturmalısınız.

Bu sorunları çözmek için:

1. UPDATE STATISTICS komutunu düzenli olarak çalıştırın ve bunu SQL Agent işi olarak zamanlayın
2. Asenkron istatistik güncellemelerini etkinleştirin (WITH ASYNC_STATS_UPDATE)
3. Trace Flag 2371’i etkinleştirerek büyük tablolarda daha sık istatistik güncellemesi sağlayın
4. Kritik sorguları tespit etmek için sys.dm_exec_query_stats DMV’sini kullanın

Gerçek performans problemleri genelde sistem loglarında değil, sorgu alışkanlıklarında gizlidir. SQL Server 2022+ ile gelen PSPO (Parameter Sensitive Plan Optimization) özelliği, yıllardır çözülmeyen bir baş ağrısına neşter vurdu. Fakat unutmamak gerekir ki, kötü yazılmış bir sorguya hiçbir versiyon ilaç olamaz.

Daha fazla istatistik sorunu tespit etmek için DMV sorgularını kullanabilirsiniz. Güncel olmayan istatistiklerle çalışan sorgular önce hızlı çalışıyor gibi görünebilir, sonra aniden yavaşlayabilir – tıpkı rastgele sorgu yürütme durumlarında olduğu gibi. Bu nedenle doğru index + güncel istatistik + etkili izleme = performansın üçlü sacayağıdır.

Outdated Statistics – Sorgular Neden Artık Akmıyor?

SQL Server sorgu optimizatörü, tahmin edilen ve gerçek satır sayıları arasındaki farkı en aza indirmek için istatistiklere güvenir. İstatistikler eski kaldığında, sorgu planları bozulur ve sorgular yavaşlar. Bu durum, özellikle sorgu yapısı değişmese bile aynı sorgunun neden bir gün hızlı, ertesi gün yavaş çalıştığını açıklar.

Auto Update OFF ya da geciken güncellemeler

SQL Server veritabanlarında varsayılan olarak Auto Update Statistics özelliği etkindir. Ancak bu ayar kapatıldığında veya tablolardaki veri değişiklikleri belirli eşiği aşmadığında istatistikler güncel kalmaz. SQL Server 2014 ve önceki sürümlerde, 500 satırdan küçük tablolarda her 500 değişiklikte, 500 satırdan büyük tablolarda ise “500 + %20” kuralına göre istatistikler güncellenir.

SQL Server 2016 ve sonraki sürümlerde ise dinamik eşik hesaplanır: Eşik = √(1000*Tablo satır sayısı). Örneğin, 1 milyon satırlı bir tabloda yaklaşık 31.622 değişiklikten sonra istatistikler otomatik güncellenir. Bununla birlikte, bu dinamik eşik hesaplaması için veritabanı uyumluluk seviyesinin 130 veya üzeri olması gerekir.

Değişen veriler istatistik histogramlarını geçersiz kılar, özellikle INSERT işlemleri istatistikleri hızla eskitir ve otomatik güncellemeler ancak %20 değişiklik eşiğine ulaşıldığında tetiklenir. İstatistikler güncel olmadığında, SQL Server sorguları için yanlış execution plan seçebilir.

Çözüm: UPDATE STATISTICS zamanlaması, async stats opsiyonu

İstatistik sorunlarını çözmek için UPDATE STATISTICS komutunu veya sp_updatestats stored procedure’ünü düzenli olarak çalıştırmak etkili bir yöntemdir. Veritabanı değişiklik oranına bağlı olarak, genellikle haftada iki kez yoğun olmayan saatlerde istatistik güncellemesi yapılması önerilir.

EXEC sp_updatestats; -- Veritabanındaki tüm istatistikleri günceller
UPDATE STATISTICS SchemeName.TableName WITH FULLSCAN; -- Belirli bir tablo için tam tarama

Ancak istatistik güncellemeleri sorguların yeniden derlenmesine neden olduğundan, çok sık güncelleme yapmaktan kaçınmalısınız. İdeal dengeyi bulmak önemlidir.

Ayrıca, “AUTO_UPDATE_STATISTICS_ASYNC” veritabanı seçeneğini etkinleştirerek asenkron istatistik güncellemesi yapabilirsiniz. Bu seçenek etkinleştirildiğinde, SQL Server istatistiklerin güncellenmesini beklemez, sorguyu mevcut istatistiklerle çalıştırır ve arka planda istatistikleri günceller. OLTP ortamlarında bu özellik faydalı olabilir, ancak veri ambarlarında daha az etkilidir.

ALTER DATABASE VeriTabanıAdı SET AUTO_UPDATE_STATISTICS_ASYNC ON;

Sonuç olarak, doğru index + güncel istatistik + etkili izleme = performansın üçlü sacayağıdır. SQL Server 2022+ ile gelen PSPO özelliği, yıllardır çözülmeyen bir baş ağrısına neşter vurdu. Ancak kötü yazılmış bir sorguya hiçbir versiyon ilaç olamaz.

Kırmızı Bayrak #5:

TempDB, SQL Server’ın en kritik sistem veritabanlarından biridir ve yanlış yapılandırılması tüm sistemi yavaşlatabilir. Özellikle sorgu yürütme planları, geçici tablolar, tablo değişkenleri ve indeks oluşturma işlemleri TempDB’yi yoğun şekilde kullanır. Yetersiz TempDB yapılandırması, performans darboğazlarına ve hatta “Could not allocate space” hatalarına yol açabilir.

Yetersiz TempDB Yapılandırması

TempDB’nin tek dosyada yapılandırılması, özellikle yoğun OLTP sistemlerinde iç metadata nesneleri (syslockinfo, sysallocunits) üzerinde yüksek sayfalama (PFS/GAM) çakışmalarına neden olur. Bu durum, birden fazla işlemin aynı anda TempDB’de yer ayırmaya çalıştığı durumlarda belirginleşir.

SQL Server programı ve veri dosyaları; sıkıştırılmış dosya sistemlerinde, sistem dosyalarının bulunduğu dizinlerde veya paylaşılan sürücülerde bulunamaz. Ayrıca, hatalı yapılandırılmış sistemlerde TempDB’nin hızlı büyümesi beklenmeyen performans sorunlarına yol açabilir.

“Could not allocate space” hatası

Bu hata genellikle TempDB’nin veri veya günlük dosyalarında yeterli alan kalmadığında ortaya çıkar. Dosyaların daha fazla büyümesine izin verilmeyen veya disk alanının tamamen dolduğu durumlarda görülür. Öte yandan, bazı filtre sürücüleri (antivirus, online yedekleme, şifreleme) SQL Server I/O yanıt süresini ciddi şekilde etkileyebilir.

Çözüm: Çoklu dosya, eşit boyut, trace flag 1117/1118, SSD tercih

TempDB için önerilen yapılandırma şunları içerir:

• Çoklu dosya kullanımı: Fiziksel CPU sayınıza kadar (maksimum 8) TempDB veri dosyası oluşturun
• Eşit boyutlandırma: Tüm TempDB dosyalarını aynı başlangıç boyutuyla ve aynı büyüme oranıyla yapılandırın
• Trace flag 1117/1118: SQL Server 2016 öncesi sürümlerde bu trace flag’ler TempDB sayfalama çakışmalarını azaltır
• SSD tercih edin: TempDB için mümkünse SSD depolama kullanın, bu I/O gecikmesini önemli ölçüde azaltır

Ayrıca, sunucuda çalışan herhangi bir filtre sürücüsünü veya modülü tanımlayın ve bunların SQL Server iş yüküne müdahale etmeyecek şekilde yapılandırılmış olduğundan emin olun. I/O gecikmesini ölçmek için Avg Disk Sec/Transfer değerlerinin tutarlı olarak 10-15 milisaniyeyi aşmaması gerekir.

Gerçek performans problemleri genelde sistem loglarında değil, sorgu alışkanlıklarında gizlidir. Bu yüzden doğru index + güncel istatistik + etkili izleme = performansın üçlü sacayağıdır.

Yetersiz TempDB Yapılandırması

TempDB, SQL Server’da geçici verilerin işlendiği kritik bir çalışma alanıdır ve sorgu yürütme, indeks oluşturma ve bakım işlemleri gibi pek çok görevde yoğun şekilde kullanılır. Doğru yapılandırılmamış TempDB, tüm veritabanı sunucusunun performansını olumsuz etkileyebilir ve beklenmedik hatalarla sonuçlanabilir.

SQL Server 2016 öncesi sürümlerde, TempDB’de yüksek eşzamanlı erişim durumlarında SGAM (Shared Global Allocation Map) sayfasında çakışmalar meydana gelir. Bu sayfalar, tüm dosya genelinde sayfa tahsisini izleyen kritik sistem sayfalarıdır. Eşzamanlı oturumlar aynı sistem sayfalarına erişmeye çalıştığında, sayfalama kilidi beklemeleri oluşur ve performans düşer.

“Could not allocate space” hatası

Bu hata genellikle TempDB’nin dosya boyutu limitlerine ulaştığında ortaya çıkar. Hata mesajı şöyle görünür: “Could not allocate space for object ‘dbo.SORT temporary run storage’ in database ‘tempdb’ because the ‘PRIMARY’ filegroup is full”. Bu sorun şu durumlarda meydana gelir:

• TempDB için otomatik büyüme (autogrowth) ayarlanmamışsa
• Dosyalar için maksimum boyut sınırlaması varsa
• Diskte yeterli boş alan kalmadığında

Özellikle eşzamanlı kullanıcı sayısı yüksek olan ortamlarda ya da büyük veri işleme iş yüklerinde TempDB hızla büyüyebilir. Ayrıca, birçok geçici tablonun veya tablo değişkeninin kullanıldığı sorgular da bu hataya yol açabilir.

Çözüm: Çoklu dosya, eşit boyut, trace flag 1117/1118, SSD tercih

TempDB performans sorunlarını çözmek için aşağıdaki yapılandırma önerilerini uygulayabiliriz:

1. Çoklu dosya kullanımı: TempDB için sunucudaki mantıksal işlemci sayısı kadar (maksimum 8) veri dosyası oluşturun. Bu, tahsis çakışmalarını azaltmaya yardımcı olur.
2. Eşit boyut ve büyüme: Tüm TempDB dosyalarını aynı başlangıç boyutuyla ve aynı büyüme oranıyla yapılandırın. Bu, SQL Server’ın dosyaları dengeli kullanmasını sağlar ve herhangi bir dosyanın performans darboğazı haline gelmesini önler.
3. SQL Server 2016+ için iyileştirmeler: SQL Server 2016 ve sonraki sürümlerde trace flag 1117 ve 1118’e artık ihtiyaç yoktur. Bu özellikler şimdi varsayılan davranıştır:
   • 1117: Dosya grubu içindeki tüm dosyaların birlikte büyümesini sağlar
   • 1118: Karışık uzantılar (mixed extents) yerine tekdüze uzantılar (uniform extents) kullanır
4. SSD depolama kullanımı: TempDB için yerel SSD sürücüler kullanmak, I/O gecikme süresini önemli ölçüde azaltır ve genel performansı %20’ye kadar iyileştirebilir.
5. TempDB ön boyutlandırma: TempDB dosyalarını tipik iş yükünüzü destekleyecek boyutta önceden ayarlayın. Bu, SQL Server’ın her başlatıldığında TempDB’yi büyütmek için zaman ve kaynak harcamasını önler.

Bununla birlikte, gerçek performans problemleri genelde sistem loglarında değil, sorgu alışkanlıklarında gizlidir. Bu yüzden doğru index + güncel istatistik + etkili izleme = performansın üçlü sacayağıdır.

Bonus: Hayat Kurtaran Komutlar

SQL Server’da performans sorunlarını çözmek için günlük hayatta kullanabileceğiniz hazır komutlar, sorun tespitini çok daha hızlı yapmanızı sağlar. DMV’ler (Dinamik Yönetim Görünümleri), veritabanı yöneticilerinin sunucu durumunu izlemek ve sorunları teşhis etmek için kullanabileceği güçlü araçlardır.

Top 5 DMV sorgusu

İşte SQL Server performans izleme için en değerli 5 DMV sorgusu:

1. En yoğun CPU kullanan sorgular:

SELECT TOP 10 qs.total_worker_time/qs.execution_count AS avg_cpu_time, 
SUBSTRING(qt.text,qs.statement_start_offset/2, 
(CASE WHEN qs.statement_end_offset = -1 
THEN LEN(CONVERT(nvarchar(max), qt.text)) * 2 
ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY avg_cpu_time DESC;

2. Eksik indeks önerileri:

SELECT migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) AS improvement_score,
mid.statement AS table_name, mid.equality_columns, mid.inequality_columns, mid.included_columns
FROM sys.dm_db_missing_index_groups mig
JOIN sys.dm_db_missing_index_group_stats migs ON mig.index_group_handle = migs.group_handle
JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle
ORDER BY improvement_score DESC;

Bloklama tespiti

Bloklama sorunlarını tespit etmek için sys.dm_exec_requests DMV’sini kullanabilirsiniz. Bu görünüm, blocking_session_id sütununu içerir ve bu değer 0’dan farklıysa, oturumun engellendiğini gösterir.

Blokaj zincirini bulmak için şu sorgu oldukça etkilidir:

WITH cteBL (session_id, blocking_these) AS (
SELECT s.session_id, blocking_these = x.blocking_these FROM sys.dm_exec_sessions s
CROSS APPLY (SELECT ISNULL(CONVERT(varchar(6), er.session_id),'') + ', '
FROM sys.dm_exec_requests er WHERE er.blocking_session_id = ISNULL(s.session_id,0)
AND er.blocking_session_id <> 0 FOR XML PATH('')) AS x (blocking_these))
SELECT s.session_id, blocked_by = r.blocking_session_id, bl.blocking_these,
batch_text = t.text FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON r.session_id = s.session_id
INNER JOIN cteBL bl ON s.session_id = bl.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE blocking_these IS NOT NULL OR r.blocking_session_id > 0;

Index analizi

İndeks parçalanma seviyesini kontrol etmek için sys.dm_db_index_physical_stats DMF’yi kullanabilirsiniz. %30’un üzerindeki parçalanma, yeniden oluşturma gerektirirken, altındaki değerler için yeniden düzenleme yeterlidir.

SELECT OBJECT_SCHEMA_NAME(ips.object_id) AS schema_name,
OBJECT_NAME(ips.object_id) AS object_name,
i.name AS index_name, i.type_desc,
ips.avg_fragmentation_in_percent,
ips.avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ips
JOIN sys.indexes i ON ips.object_id = i.object_id AND ips.index_id = i.index_id
WHERE ips.page_count > 100
ORDER BY ips.avg_fragmentation_in_percent DESC;

Daha fazla senaryo için dmcteknoloji.com’ ve caglarozenc.com u takip etmeyi unutma!

Sonuç olarak, gerçek performans problemleri genelde sistem loglarında değil, sorgu alışkanlıklarında gizlidir. SQL Server 2022+ ile gelen PSPO özelliği yıllardır çözülemeyen sorunlara çözüm getirse de, kötü yazılmış sorguya hiçbir versiyon ilaç olamaz. Doğru index + güncel istatistik + etkili izleme = performansın üçlü sacayağıdır.

Sen de kendi veritabanını kontrol etmek ister misin?

Bu makalede tartıştığımız SQL Server performans sorunları, günlük hayatta karşılaşabileceğiniz senaryoların sadece bir kısmını oluşturuyor. Her veritabanı ortamı kendine özgü yapıya sahip olduğundan, farklı zorluklar da beraberinde gelir. Özellikle karmaşık sistemlerde performans iyileştirme bir yolculuktur, tek seferlik bir çözüm değil.

Daha fazla senaryo için dmcteknoloji.com’u ve caglarozenc.com takip etmeyi unutma!

Ayrıca SQL Server ve veritabanı performansı hakkında daha fazla senaryoya ulaşmak için dmcteknoloji.com’u ve caglarozenc.com adreslerini takip edebilirsiniz. Bu kaynaklarda SQL Server’ın derinliklerine inen makaleler, pratik çözümler ve güncel bilgiler bulabilirsiniz. Caglarozenc.com üzerinden SQL Profiler hakkında ücretsiz e-kitaba da erişebilirsiniz. Bununla birlikte “SQL Öğreniyorum” etiketli içerikler sayesinde bilgilerinizi sürekli güncel tutabilirsiniz.

Gerçek performans problemleri genelde sistem loglarında değil, sorgu alışkanlıklarında gizlidir. SQL Server 2022+ ile gelen PSPO (Parameter Sensitive Plan Optimization) özelliği, yıllardır çözülmeyen bir baş ağrısına neşter vurdu. Ama unutmamak gerekir ki; kötü yazılmış bir sorguya hiçbir versiyon ilaç olamaz. O yüzden doğru index + güncel istatistik + etkili izleme = performansın üçlü sacayağıdır.

Bu yazıyı paylaş, ekip arkadaşlarının da hayatı kolaylaşsın.

Öğrendiklerinizi paylaşmak, sadece ekip arkadaşlarınızın hayatını kolaylaştırmakla kalmaz, aynı zamanda kendi bilginizi de pekiştirir. Her okuyucunun paylaştığı bir ipucuyla, hep birlikte yüzlerce faydalı pratik ipucu elde edebiliriz. Dolayısıyla SQL Server konusunda yararlı bulduğunuz ipuçlarını iş arkadaşlarınızla paylaşın.

T-SQL ve SQL Server konusunda yeni başlıyorsanız, bilgilerinizi derinleştirmek için eğitimlere katılmayı düşünebilirsiniz. Sonuç olarak, hepimiz birbirimizden öğrenebiliriz ve sürekli gelişen veritabanı teknolojileri dünyasında güncel kalmak için bilgi paylaşımı vazgeçilmezdir.

Özetle;

SQL Server performans sorunlarını tespit etmek ve çözmek için bu kritik kırmızı bayrakları takip edin:

• İndeks eksikliği Table Scan’e neden olur – Missing Index DMV’leri kullanarak eksik indeksleri tespit edin ve INCLUDE sütunlarıyla sorgu performansını %40’a kadar artırın

• Parametre hassasiyetli planlar aynı sorguyu farklı hızlarda çalıştırır – OPTION (RECOMPILE) veya SQL Server 2022+ PSPO özelliğiyle çözün

• Blocking ve deadlock’lar sistemi sessizce yavaşlatır – sp_whoisactive ve Extended Events kullanarak blokaj zincirlerini tespit edin

• Güncel olmayan istatistikler yanlış execution plan seçimine yol açar – UPDATE STATISTICS zamanlaması ve async stats opsiyonuyla istatistikleri güncel tutun

• TempDB yapılandırması tüm sistemi etkiler – Çoklu dosya, eşit boyut ve SSD kullanımıyla “Could not allocate space” hatalarını önleyin

Unutmayın: Doğru index + güncel istatistik + etkili izleme = performansın üçlü sacayağıdır. Gerçek performans problemleri genelde sistem loglarında değil, sorgu alışkanlıklarında gizlidir. SQL Server 2022+ PSPO özelliği yıllardır çözülmeyen sorunlara çare olsa da, kötü yazılmış sorguya hiçbir versiyon ilaç olamaz.

SSS – Sık Sorulan Sorular

S1. SQL Server’da performans sorunlarının en yaygın nedenleri nelerdir? SQL Server’da performans sorunlarının başlıca nedenleri arasında eksik veya yanlış indeks kullanımı, güncel olmayan istatistikler, parametre hassasiyetli planlar, blocking ve deadlock durumları ve yetersiz TempDB yapılandırması yer alır.

S2. İndeks eksikliği SQL Server performansını nasıl etkiler? İndeks eksikliği, SQL Server’ın sorguları çalıştırırken tüm tabloyu taramasına (Table Scan) neden olur. Bu durum, özellikle büyük tablolarda sorgu performansını önemli ölçüde düşürür ve sistem kaynaklarını gereksiz yere tüketir.

S3. Parametre hassasiyetli planlar nedir ve nasıl çözülür? Parametre hassasiyetli planlar, aynı sorgunun farklı parametre değerleriyle çok farklı performans göstermesi durumudur. Bu sorun OPTION (RECOMPILE) kullanılarak veya SQL Server 2022+’daki PSPO özelliği ile çözülebilir.

S4. SQL Server’da blocking ve deadlock durumlarını nasıl tespit edebilirim? Blocking ve deadlock durumlarını tespit etmek için sp_whoisactive stored procedure’ünü, Extended Events’i ve Deadlock Graph analizini kullanabilirsiniz. Ayrıca, sys.dm_exec_requests DMV’si de blokaj zincirlerini bulmak için etkili bir araçtır.

S5. TempDB yapılandırması neden önemlidir ve nasıl optimize edilmelidir? TempDB, SQL Server’ın geçici verileri işlediği kritik bir alandır ve yanlış yapılandırılması tüm sistem performansını etkileyebilir. TempDB’yi optimize etmek için çoklu dosya kullanımı, eşit boyutlandırma, SSD depolama tercihi ve SQL Server sürümüne bağlı olarak trace flag 1117/1118 kullanımı önerilir.